CVE-2026-45930

What it actually does

A local, low-privileged user can trigger Linux kernel MCTP netlink response paths, including RTM_GETNEIGH, that return structures with uninitialized padding bytes. Those bytes may contain stale kernel memory from prior allocations. The flaw does not provide a direct remote attack path or obvious code execution primitive, but it can expose unintended kernel memory contents to a local user through NETLINK_ROUTE responses.

Why it matters to the business

The main risk is unintended disclosure of kernel memory on Linux systems where untrusted local users, workloads, or containers can reach the affected MCTP netlink interfaces. In shared compute, CI/CD, hosting, appliance, or multi-tenant Linux environments, this can weaken isolation and may expose sensitive operational data. Exploitation probability is currently low based on the very low EPSS score, lack of KEV listing, and no reported mature exploit, but kernel flaws should still be prioritized for routine patching because fixes often require coordinated reboots.

How an attack unfolds

An attacker first needs local access to a Linux system with the affected kernel code available. They open a NETLINK_ROUTE socket and issue MCTP-related netlink queries, such as RTM_GETNEIGH, that cause the kernel to build link, address, or neighbor response messages. Because the affected code did not fully zero-initialize the response structures, padding bytes in the returned ndmsg data can contain stale memory. The attacker repeatedly requests these messages and inspects the returned padding bytes, attempting to recover useful fragments of kernel memory. The vulnerability is most relevant where local users or sandboxed workloads are not fully trusted.

How to fix it

Upgrade to a Linux kernel version from the system vendor or distribution that includes the fix for MCTP netlink response zero-initialization. Because no exact fixed package versions were provided, use the latest security-supported kernel available for each affected distribution and verify that it contains the upstream fix for initializing MCTP link, address, and neighbor netlink response data. Reboot systems after installing the kernel so the fixed kernel is active. If immediate patching is not possible and MCTP is not required, reduce exposure by disabling or preventing loading of MCTP-related kernel modules where supported, restricting local shell access, limiting untrusted workloads, and enforcing container isolation; treat these as temporary mitigations, not substitutes for patching.

How to confirm the fix worked

Confirm that the running kernel, not only the installed package, has been updated by checking uname -r and comparing it with the vendor advisory or package changelog. Review distribution kernel changelogs for references to MCTP netlink response initialization, RTM_GETNEIGH, ndmsg padding, or zero-initialization of link, address, and neighbor responses. If MCTP is not needed and has been disabled as a mitigation, verify that MCTP modules are not loaded and cannot be auto-loaded. For deeper validation, run a controlled regression test that issues MCTP RTM_GETNEIGH-style netlink queries and confirms padding bytes in responses are consistently zeroed rather than containing variable stale data.

Typical attack path

1. Obtain local code execution or an interactive account on an affected Linux host.
2. Verify that the running kernel supports MCTP/netlink functionality relevant to neighbor, address, or link queries.
3. Open a NETLINK_ROUTE socket from user space.
4. Send MCTP-related RTM_GETNEIGH or related netlink query messages.
5. Receive the kernel netlink response and parse the ndmsg payload and padding bytes.
6. Repeat requests to collect stale uninitialized bytes and analyze them for potentially sensitive kernel memory fragments.

How to detect it

Reliable post-compromise detection is difficult because exploitation consists of local netlink queries that are normally not logged by default and do not necessarily create files, network connections, crashes, or persistent artifacts. Investigators should review auditd, eBPF telemetry, EDR, or syscall tracing data if available for suspicious local processes opening NETLINK_ROUTE sockets and repeatedly issuing RTM_GETNEIGH or MCTP-related netlink requests. Focus on untrusted user accounts, container workloads, CI jobs, temporary directories, and recently executed binaries or scripts. Shell history, process accounting, and EDR command-line telemetry may reveal custom proof-of-concept tools, unusual MCTP enumeration utilities, or repeated netlink probing. Kernel logs are unlikely to show exploitation unless additional tracing was enabled. Because there are no public exploit artifacts, no KEV listing, and no named threat actors reported for this issue, absence of indicators should not be treated as proof that exposure did not exist.

What your security team should do

• Inventory Linux systems and kernel versions, prioritizing multi-user hosts, container hosts, CI runners, shared development systems, appliances, and systems that allow untrusted local code execution.
• Apply vendor kernel security updates and schedule required reboots; do not rely on package installation alone without activating the fixed kernel.
• Prioritize patching during the next maintenance cycle; increase urgency for shared or multi-tenant systems despite the currently low EPSS and absence from CISA KEV.
• Where MCTP is not operationally required, disable or block MCTP-related kernel modules until patching is complete.
• Restrict local access and untrusted workload execution on affected systems, especially where users can create netlink sockets.
• Monitor for unusual local netlink enumeration activity, especially repeated RTM_GETNEIGH requests involving MCTP address families.
• Document compensating controls and reboot status because kernel vulnerabilities commonly remain exposed when systems are updated but not restarted.