CVE-2026-74694: Linux Kernel NCSI Information Disclosure

CVE-2026-74694 Overview

CVE-2026-74694 is a heap out-of-bounds read vulnerability in the Linux kernel's NCSI (Network Controller Sideband Interface) subsystem. The flaw resides in ncsi_send_cmd_nl() within net/ncsi, which trusts the attacker-controlled ncsi_pkt_hdr.length field without cross-checking it against the size of the source netlink attribute. An attacker with CAP_NET_ADMIN on a system with a registered NCSI device can trigger ncsi_cmd_handler_oem() to copy up to approximately 64KB past the end of the netlink attribute buffer. The result is a kernel heap information leak transmitted inside an outbound NCSI command packet. The issue was reported by the autokbug dynamic kernel fuzzer at Tencent Yunding Lab.

Critical Impact
A local privileged actor can leak up to ~64KB of kernel heap memory per crafted NCSI netlink command, exposing pointers, credentials, and other sensitive kernel data that undermine KASLR and other memory protections.

Affected Products

Linux kernel builds with NET_NCSI=y (commonly OpenBMC on Aspeed BMC SoCs)
Systems exposing NCSI netlink command handling with a registered NCSI device
Multiple stable Linux kernel branches (see referenced git commits for backports)

Discovery Timeline

Vulnerability discovered by the autokbug dynamic kernel fuzzer at Tencent Yunding Lab
2026-08-22 - CVE-2026-74694 published to NVD
2026-08-22 - Last updated in NVD database

Technical Details for CVE-2026-74694

Vulnerability Analysis

The vulnerability is a classic length-confusion bug between two independently sized buffers. ncsi_send_cmd_nl() accepts an NCSI command from userspace through a netlink interface. The command contains an in-band ncsi_pkt_hdr structure whose length field declares the payload size the kernel should copy. The kernel validates only that nla_len() >= sizeof(struct ncsi_pkt_hdr) before proceeding.

The kernel never verifies that hdr->length fits within the readable portion of the NCSI_ATTR_DATA attribute, which is nla_len() - sizeof(ncsi_pkt_hdr) bytes. When ncsi_cmd_handler_oem() reaches its unsafe_memcpy() call, it copies hdr->length bytes from the attribute buffer into a destination skb sized by the declared payload. The destination is large enough, so the write side is safe. However, the read side walks past the end of the attribute allocation into adjacent kernel heap memory.

Root Cause

The root cause is missing cross-validation between two attacker-influenced length sources: the attribute length reported by netlink and the payload length declared inside the packet header. Because the readable source size can be as small as 2032 bytes while hdr->length is a 16-bit field allowing values up to 65535, the mismatch enables an out-of-bounds read of tens of kilobytes of kernel heap. Classification aligns with [CWE-125] Out-of-bounds Read.

Attack Vector

Exploitation requires local CAP_NET_ADMIN on a system with a registered NCSI device, such as an OpenBMC deployment on Aspeed BMC hardware. The attacker crafts a netlink NCSI_CMD_SEND_CMD message with a small NCSI_ATTR_DATA attribute but sets ncsi_pkt_hdr.length to a value far exceeding the attribute payload. The kernel then constructs an outbound NCSI command packet whose body is populated with data read past the attribute buffer. Reading that transmitted packet, either on the wire or via loopback capture, exposes the leaked kernel heap contents to the attacker.

No verified public exploit code is available. See the kernel git commit fixing the issue for the corrected length check.

Detection Methods for CVE-2026-74694

Indicators of Compromise

Netlink NCSI_CMD_SEND_CMD messages where the header length field exceeds the size of the accompanying NCSI_ATTR_DATA payload.
Outbound NCSI command frames whose declared payload size is inconsistent with expected OEM command sizes on the BMC sideband interface.
Processes holding CAP_NET_ADMIN interacting with the NCSI generic netlink family outside of expected BMC management tooling.

Detection Strategies

Audit kernel auditd records for netlink syscalls targeting the NCSI generic netlink family and correlate with the invoking binary and user identity.
Enable kernel address sanitizer (KASAN) builds in test and staging environments to catch out-of-bounds reads in ncsi_cmd_handler_oem().
Inspect BMC-adjacent hosts for unusual NCSI command traffic patterns using packet capture on the sideband interface.

Monitoring Recommendations

Log and alert on invocations of NCSI netlink commands from any process other than authorized management daemons.
Track running kernel versions across fleets to confirm that patched builds are deployed on all BMC-enabled hardware.
Monitor CAP_NET_ADMIN grants and namespace configurations that could expose the NCSI netlink API to less-privileged workloads.

How to Mitigate CVE-2026-74694

Immediate Actions Required

Apply the upstream Linux kernel patch that rejects NCSI commands whose declared payload extends past the end of the NCSI_ATTR_DATA attribute.
Restrict CAP_NET_ADMIN on systems with NET_NCSI=y, particularly OpenBMC and Aspeed BMC deployments, to trusted management processes only.
Rebuild and redeploy BMC firmware images that ship a fixed kernel across all affected hosts.

Patch Information

Upstream fixes are available in the following stable kernel commits: 02226af6, 3a60b5af, 43c7d0a6, 4489b4a1, 67c72b8e, afa58b73, b5231ad0, and e60afa01. Each patch adds a length check ensuring hdr->length does not exceed the readable portion of the netlink attribute.

Workarounds

On systems that do not require NCSI, build kernels with CONFIG_NET_NCSI=n to remove the vulnerable code path entirely.
Where the feature is required, constrain administrative access so that only vetted BMC management daemons can send NCSI generic netlink commands.
Isolate BMC and management networks so that a compromised host cannot receive leaked NCSI command packets from other systems.

bash

# Verify NCSI is disabled or confirm the running kernel includes the fix
grep CONFIG_NET_NCSI /boot/config-$(uname -r)
uname -r

# Restrict CAP_NET_ADMIN for non-management workloads via systemd
# Example unit hardening directives:
#   CapabilityBoundingSet=
#   AmbientCapabilities=
#   RestrictAddressFamilies=AF_UNIX AF_INET AF_INET6