The Linux kernel disclosure tracked as
CVE-2024-49945 fixes a subtle but meaningful resource-management bug in the Network Controller Sideband Interface (NCSI) driver: the kernel was freeing an NCSI device structure while a scheduled work item could still run against it, creating a classic
use-after-free that can cause kernel panics and a sustained denial-of-service for affected systems. The upstream patch adds a synchronous disable/drain of the NCSI work item before freeing the structure — effectively preventing the workqueue callback from accessing memory after it has been released. This vulnerability has been assigned a CVSS v3.1 base score of
5.5 (Medium), with
high impact to availability while requiring local access and
low privileges to trigger on vulnerable kernels.
Background
What is NCSI and why it matters
NCSI (Network Controller Sideband Interface) is a DMTF-defined mechanism that allows out-of-band management controllers — typically a BMC (Baseboard Management Controller) — to share physical NIC ports with the host. NCSI is commonly present on server-class hardware where a single Ethernet port can carry both host data and management traffic; the BMC and host coordinate via NCSI commands to distinguish and forward appropriate frames. Because NCSI operates at a low level and is commonly present on servers and appliances, bugs in the net/ncsi subsystem can affect critical infrastructure and management connectivity.
The kernel workqueue model (brief)
Linux device drivers frequently use
workqueues to defer processing to context where sleeping is permitted. A driver schedules a
work_struct (or
delayed_work) and the kernel runs the associated callback later. Correct shutdown semantics demand that the driver prevent further runs of that work and wait for any in-progress callback to complete before freeing the object the callback touches. Failure to do so creates a time-of-use-after-free window. The kernel provides primitives such as
cancel_work_sync,
cancel_delayed_work_sync, and the newer
disable_work_sync to ensure a work item is cancelled/drained safely.
The Vulnerability: what went wrong
Root cause
The net/ncsi subsystem’s unregister pathway freed an internal
ncsi_dev (or associated
ndp) structure without first disabling and draining the work item that references it. Under the right race conditions the scheduled work callback could be invoked
after the free, resulting in a use-after-free and likely kernel panic. In short: the code sequence freed memory while concurrent deferred code still had pointers to it. The upstream fix inserts a call to disable-and-wait (in most trees
disable_work_sync or where backporting requires it,
cancel_work_sync or the appropriate delayed variant) before the
kfree of the ncsi object.
What the patch actually does
The applied changes are small but decisive: immediately before
kfree(ndp), the kernel now calls the work-drain primitive to guarantee the associated work is neither pending nor executing. Newer mainline trees use
disable_work_sync(&ndp->work) in the unregister function; some stable/backport branches use
cancel_work_sync(&ndp->work) depending on available workqueue APIs in that release. The net effect is identical from a correctness perspective: the work item cannot run after the object is freed.
Affected kernels and distributions
Kernel ranges reported as vulnerable
Public vulnerability trackers and distro advisories indicate the vulnerable code is present across multiple kernel series that historically carried the NCSI driver. Reported vulnerable ranges include kernels from 4.8 through releases before 6.10.14 in one mapping, and additional churn around the 6.11/6.12 release candidates where the bug was introduced/fixed. The Linux project’s own CNA entry and multiple distro trackers list the canonical fix commits applied to stable trees. Administrators should treat kernels that predate the stable fix as vulnerable until vendor patches are applied.
Distribution advisory posture (representative)
- Debian and Ubuntu have published tracking entries and released kernel updates or backports for affected releases; Debian notes a fixed package in the unstable branch (e.g., 6.11.4-1 in some trees) while Ubuntu lists a set of linux-image updates and USNs that include the fix.
- SUSE lists the issue as resolved and assigns the same CVSS vector and severity rating. Enterprise cloud images (for example, Amazon Linux) may not be affected depending on kernel configuration and shipping kernels; check vendor advisories per platform.
Note: the exact package name and fixed version vary by vendor and release; always consult your distribution’s security advisory and the package changelog for the authoritative patch level.
Impact and exploitability
What an attacker can do
The vulnerability is primarily an
availability issue: successful triggering can produce kernel panics and sustained or persistent denial-of-service (systems that repeatedly panic or whose network stack becomes unusable). The CVSS vector is assessed as Local (AV:L), Low complexity, Low privileges required, and
High availability impact — reflecting that an attacker with local access could cause a crash but cannot, from public information, read secrets or directly alter persisted data.
Who is at greatest risk
Systems that expose NCSI — typical BMC-enabled servers and appliances — are the highest-value targets because they commonly run NCSI to share NICs between host and management. Desktop and laptop machines rarely enable NCSI, so risk there is much lower. Cloud and VPS providers that use custom kernels or omit NCSI are likewise less exposed; conversely, enterprise data center servers with integrated BMCs are most at risk.
Exploit code and real-world exploitation
As of the time of writing, there is
no widely reported public proof-of-concept (PoC) exploit tied to CVE-2024-49945. The vulnerability is a kernel-space use-after-free — a class that has historically been exploited to obtain code execution or persistent denial-of-service — but whether an attacker can reliably gain escalation beyond DoS depends on kernel mitigations (KASLR, SMAP/SMEP, hardened configurations) and the specific memory layout. Organizations should assume functional PoCs are feasible to develop and prioritize patches accordingly, especially for servers and management-plane equipment. This claim is based on public advisories and vulnerability trackers which list the issue’s technical impact but do not cite a PoC in the wild.
If exploit or PoC artifacts emerge, the situation may change quickly.
Detection: how to know if you’re exposed
Start with the basic question: does your kernel enable NCSI and is it the specific kernel version or vendor package that contains the unfixed code?
Useful checks and commands:
- Check kernel version:
uname -rcat /proc/version
- Check whether NCSI support is built/loaded:
- If NCSI is a module:
lsmod | grep ncsi
- Kernel config (if available):
zgrep CONFIG_NET_NCSI /proc/config.gz or check /boot/config-$(uname -r) for CONFIG_NET_NCSI=y or m.
- Inspect dmesg and syslog for NCSI lines:
dmesg | grep -i ncsijournalctl -k | grep -i ncsi
- Look for NCSI channel devices or carrier indications:
for i in /sys/class/net/*; do echo $i; cat $i/carrier 2>/dev/null || true; done — NCSI-managed interfaces often show up alongside other NICs on servers using sideband management.
- Cross-reference with distribution advisories: search your vendor security feed for CVE-2024-49945 and look for fixed package names and versions.
If your kernel does not have
CONFIG_NET_NCSI enabled, or your vendor’s kernel package is listed as
not affected, you do not need to take immediate remediation action beyond normal patching discipline. However, for servers with BMCs and shared NICs, treat this as a priority to verify.
Mitigation and remediation
The recommended fix: update the kernel
The definitive remediation is to install vendor-provided security updates that include the backported fix for the net/ncsi unregister path, then reboot into the patched kernel. Most major Linux distributors have released updates or provided guidance — for instance Debian, Ubuntu, and SUSE have tracked and deployed fixes in their kernels. Always install the kernel package versions recommended in your distro’s security advisory rather than cherry-picking individual commits.
- Update packages via your package manager:
- Debian/Ubuntu:
apt update && apt full-upgrade (or install specific linux-image package versions listed in USNs/security advisories)
- RHEL/CentOS/AlmaLinux:
dnf update kernel* (refer to vendor errata)
- SUSE:
zypper patch or apply the kernel livepatch if available
- Reboot to the updated kernel to ensure the patched code is running.
- Verify
uname -r reflects a patched release and re-check for NCSI-related dmesg messages.
Short-term workarounds if patching is not immediately possible
- Disable or blacklist the NCSI module — if NCSI is provided as a module (
ncsi), unloading and blacklisting it prevents the vulnerable path from being exercised. Use:
modprobe -r ncsi (careful: unloading may disrupt management-plane connectivity)- Add
blacklist ncsi to /etc/modprobe.d/ to prevent later loads
Note: some distributions build NCSI into the kernel rather than as a module; in that case, blacklisting is not possible.
- Disable NCSI in firmware/BIOS — many server platforms allow disabling sideband interfaces or BMC-host sharing in the firmware. This is an acceptable mitigation for systems where out-of-band management is not required or can be temporarily disabled.
- Network segmentation and access controls — limit local access to systems with NCSI-enabled hardware (restrict physical/local management networks) to reduce the risk of local attackers executing the required steps to trigger the bug.
Caveat: unloading or disabling NCSI may cut off legitimate BMC-host functionality and management traffic. Use mitigations only after evaluating operational impact.
Operational guidance and prioritization
- Prioritize servers and appliances with BMC/NCSI usage. Inventory your fleet to identify systems with BMCs (IPMI/iLO/iDRAC/Redfish endpoints) and determine whether they share NICs via NCSI.
- Treat the issue as a high-availability risk. Although the CVSS score is medium overall, the availability impact is high; for production hosts that service critical workloads, schedule kernel upgrades during maintenance windows.
- Apply vendor patches promptly and verify. Use vendor-supplied packages; avoid hand-building kernels in production unless you follow strict QA that includes the relevant backported change.
- Monitor for signs of exploitation. Look for unexplained kernel panics, repeated reboots, or dmesg traces showing NCSI work callbacks failing. Add detection rules to SIEMs and host monitoring systems to alert on NCSI-related kernel messages.
- Document and test rollback procedures. Kernel updates require reboots; ensure rollback images or recovery mechanisms are in place in case of regressions.
Why the fix is appropriate — a technical assessment
The patch follows established kernel hygiene: ensure work items that reference object memory are synchronously disabled and drained before the object is freed. The change is minimal and local to the unregister code path, reducing the chance of regression elsewhere. Use of
disable_work_sync (when available) is the modern approach because it both cancels pending work and prevents future re-queueing while waiting for any in-flight callback to finish; where newer workqueue APIs are not present, maintainers used
cancel_work_sync or the delayed variants. This is a robust repair that addresses the concurrency window directly rather than trying to restructure higher-level logic. Potential limitations:
- If a downstream vendor delayed or missed the backport, their kernels remain vulnerable; proactive patch management is required.
- If NCSI is compiled into the kernel (not modular), a temporary workaround like blacklisting is not possible without rebuilding kernels or applying alternative mitigations (BIOS-level disablement).
- The patch does not change attack-vector prerequisites: the vulnerability still requires local access or a path to trigger the NCSI code. For multi-tenant or exposed management lanes, this remains a realistic concern.
Risk summary and recommendations
- Risk level for servers with NCSI: Elevated. These systems often host critical services and are reachable by privileged management networks; a kernel panic here can cause sustained service outages. Apply vendor kernel updates immediately.
- Risk level for desktops and workstations: Low, unless NCSI is explicitly enabled (rare).
- Exploit maturity: No public PoC widely reported at publication time, but the underlying class of bug (kernel use-after-free) has historically been weaponized; prepare as though exploitation is feasible.
- Recommended action: Inventory devices for NCSI, prioritize patch rollouts to exposed servers, and apply mitigation steps (module unload or firmware disable) where patching cannot be immediate.
Conclusion
CVE-2024-49945 is a textbook concurrency/resource-management bug in the net/ncsi driver: the kernel could free an NCSI device object while a deferred work callback was still allowed to run, creating a use-after-free and possible kernel panic. The upstream fix is straightforward and correct — synchronously disabling and draining the work before freeing the memory — and has been backported into stable kernels and packaged by major distributors. The pragmatic response for administrators is clear: identify NCSI-enabled systems, prioritize kernel updates from your vendor, and, when necessary, use cautious workarounds (module unloading or firmware-level disablement) until a patched kernel can be deployed. Because the vulnerability specifically threatens availability and affects management-plane hardware in data centers, even an otherwise “medium” CVSS score warrants prioritized remediation for production and infrastructure hosts.
Quick reference (operator checklist)
- Identify NCSI usage:
lsmod | grep ncsi, zgrep CONFIG_NET_NCSI /boot/config-$(uname -r)
- Check kernel advisory for your distro and install listed fixes.
- Reboot into patched kernel and confirm
uname -r.
- If immediate patching is impossible: consider
modprobe -r ncsi or BIOS/firmware NCSI disable (evaluate operational impact).
- Monitor for kernel panic symptoms, NCSI messages in
dmesg, and vendor security feeds for PoC/exploit updates.
Stay current with vendor advisories and treat kernel fixes to net drivers — especially those touching out-of-band management — as high-priority for critical systems.
Source: MSRC
Security Update Guide - Microsoft Security Response Center