CVE-2026-43373

What it actually does

The flaw is a memory leak in Linux kernel NCSI receive paths. When malformed or unexpected NCSI Asynchronous Event Notification packets or NCSI response packets are received, error-handling paths in ncsi_aen_handler() and ncsi_rcv_rsp() can return without freeing the associated socket buffer, leaving kernel memory allocated. Repeated triggering can progressively consume kernel memory and cause availability degradation, packet processing failures, out-of-memory conditions, or a kernel panic/reboot. The issue does not provide confidentiality or integrity impact by itself, but it can be used for denial of service against systems using NCSI-capable network hardware or management sideband interfaces.

Why it matters to the business

A vulnerable system can be made unstable or unavailable if an attacker can deliver crafted NCSI traffic to the affected network path. Operational impact may include server outages, degraded network connectivity, emergency reboots, failed workloads, and disruption of management-plane access. Although this issue is not currently in CISA KEV, has no known mature public exploit, and has a low EPSS score, the CVSS availability impact is high, so organizations with exposed or shared management networks, untrusted BMC/NIC paths, or high-availability Linux infrastructure should prioritize patching during the next appropriate maintenance window.

How an attack unfolds

An attacker first needs a network position that can influence NCSI traffic reaching a vulnerable Linux host, such as access to a management network, a compromised or malicious baseboard management controller, a compromised NIC-side component, or another path capable of injecting NCSI Ethernet frames. The attacker sends invalid AEN packets or unexpected NCSI response packets that cause the kernel NCSI receive handler to take an early error return. Because the vulnerable error path does not release the received skb, each packet leaves a small amount of kernel memory allocated. By repeatedly sending such packets, the attacker steadily increases unreclaimed kernel memory consumption. Eventually the host may experience memory pressure, packet drops, OOM-killer activity, service failures, loss of network functionality, or a kernel panic/reboot, resulting in denial of service.

How to fix it

Upgrade the Linux kernel to a vendor-supported release that includes the NCSI skb leak fix for ncsi_aen_handler() and ncsi_rcv_rsp(). No exact fixed package versions were provided, so use distribution security advisories and kernel changelogs to identify the first corrected release for each platform. Where immediate patching is not possible, reduce exposure by isolating management networks, restricting access to BMC/NIC sideband paths, blocking untrusted access to NCSI-capable segments, and monitoring for abnormal NCSI traffic or memory growth. Rebooting may temporarily clear leaked memory but does not remediate the underlying vulnerability.

How to confirm the fix worked

Confirm that the running kernel package or vendor kernel build contains the upstream NCSI skb leak fix. Validate after reboot that the patched kernel is active, not merely installed. Review vendor advisories, kernel changelogs, or source patches for changes ensuring received skb objects are consumed or freed on all error paths in ncsi_aen_handler() and ncsi_rcv_rsp(). Operationally, monitor /proc/slabinfo, kernel memory pressure, and dmesg while observing normal NCSI traffic; on fixed systems, malformed or unexpected NCSI traffic should not cause persistent growth in skb-related slab allocations or repeated OOM behavior. Also confirm that management network access controls prevent untrusted systems from injecting NCSI or sideband management traffic.

Typical attack path

1. Identify Linux systems that use NCSI-capable network hardware or management sideband connectivity.
2. Gain the ability to send or influence NCSI traffic on the relevant management or sideband network path.
3. Transmit malformed or unexpected NCSI AEN or response packets that trigger early-return error handling in the kernel NCSI receive path.
4. Repeat the traffic to accumulate unreleased socket buffers in kernel memory.
5. Cause memory pressure, degraded networking, OOM events, kernel instability, or host reboot, resulting in denial of service.

How to detect it

To determine whether the issue was already exploited, review kernel logs, system journals, crash dumps, BMC logs, management-network flow data, and packet captures around periods of instability. Look for unexplained kernel memory pressure, skb-related slab growth, OOM-killer events, network stack allocation failures, soft lockups, kernel panics, or reboots that coincide with unusual NCSI traffic. Network monitoring should focus on Ethernet frames using the NCSI EtherType 0x88F8, especially bursts of malformed AEN packets or unexpected responses from unauthorized sources on management or sideband networks. Host telemetry can include /proc/slabinfo trends for sk_buff-related caches, dmesg messages about allocation failures, and journal entries showing OOM activity. There are no public exploit-specific payload strings for this CVE, so detection should combine memory-exhaustion symptoms with evidence of abnormal NCSI traffic or unauthorized management-network activity.

• EtherType 0x88f8
• EtherType 0x88F8
• NCSI
• ncsi
• ncsi_aen_handler
• ncsi_rcv_rsp
• skbuff_head_cache
• skb
• Out of memory
• oom-killer
• Memory cgroup out of memory
• page allocation failure
• kernel panic
• soft lockup
• BUG: unable to handle kernel paging request

What your security team should do

• Inventory Linux systems with NCSI-capable NICs, BMC sideband connectivity, or management network exposure.
• Prioritize patching for production servers, virtualization hosts, storage nodes, and other systems where host availability is critical.
• Apply the vendor-provided kernel update that includes the NCSI skb leak fix, then reboot into the corrected kernel.
• Segment and restrict management networks so only authorized management controllers and administrative systems can communicate on those paths.
• Monitor for abnormal NCSI Ethernet traffic, repeated kernel memory pressure, skb slab growth, OOM-killer events, unexpected reboots, or degraded network behavior.
• If unexplained OOM or reboot events occurred before patching, preserve kernel logs, network telemetry, BMC logs, and packet captures from management networks for investigation.
• Because the issue is not currently KEV-listed and EPSS is low, treat it as a targeted availability risk rather than evidence of broad active exploitation, while still addressing exposed management-plane environments promptly.