CVE-2026-43455: Linux Kernel Race Condition Vulnerability

CVE-2026-43455 Overview

CVE-2026-43455 is a race condition vulnerability in the Linux kernel's Management Component Transport Protocol (MCTP) routing code. The flaw resides in mctp_flow_prepare_output(), which checks key->dev and may call mctp_dev_set_key() without holding key->lock. Concurrent transmit paths through mctp_sendmsg() can race on the same key, causing one device reference to be acquired but never released. The result is a kernel resource leak tied to MCTP device references. Upstream maintainers have resolved the issue by taking key->lock around the check-and-set sequence.

Critical Impact
Concurrent MCTP send operations can leak net_device references through unsynchronized access to key->dev, leading to kernel resource exhaustion over time.

Affected Products

Linux kernel versions containing the MCTP routing code prior to the fix
Stable kernel branches referenced in commits 0695712, 4789316, 7d86aa4, 86f5334, 8d27d9b, and 925a5ff
Systems using MCTP networking (commonly BMC and platform management stacks)

Discovery Timeline

2026-05-08 - CVE-2026-43455 published to NVD
2026-05-12 - Last updated in NVD database

Technical Details for CVE-2026-43455

Vulnerability Analysis

The vulnerability is a race condition in the MCTP transmit path of the Linux kernel networking stack. The function mctp_flow_prepare_output() reads key->dev and conditionally calls mctp_dev_set_key() to bind a device to the routing key. Both mctp_dev_set_key() and mctp_dev_release_key() are annotated __must_hold(&key->lock), indicating that key->dev access must be serialized by key->lock. The transmit path reaches mctp_flow_prepare_output() via mctp_local_output() and mctp_dst_output() without acquiring that lock, breaking the locking contract.

Root Cause

The root cause is missing lock acquisition around a check-and-set operation [CWE-362]. When two CPUs concurrently execute mctp_flow_prepare_output() for the same key with different devices, both can observe key->dev as NULL and proceed to call mctp_dev_set_key(). Each call invokes mctp_dev_hold() to take a reference, but only the final assignment to key->dev is tracked for later release. The earlier reference becomes unreachable, producing a net_device reference leak.

Attack Vector

Exploitation requires local code paths capable of issuing concurrent MCTP sendmsg operations against the same routing key. An unprivileged or local attacker with the ability to send MCTP traffic can repeatedly trigger the race to leak device references. Sustained triggering prevents affected net_device objects from being freed, degrading kernel resource availability over time. The flaw does not provide direct code execution, but the resource leak can contribute to denial-of-service conditions on long-running systems.

No public proof-of-concept code is associated with this CVE. The technical details are documented in the kernel commit messages linked in the references below.

Detection Methods for CVE-2026-43455

Indicators of Compromise

Growing net_device reference counts on MCTP-capable interfaces with no corresponding release
Kernel warnings about devices that cannot be unregistered or removed cleanly
Increasing memory pressure or slab consumption tied to networking structures on hosts using MCTP

Detection Strategies

Audit kernel versions across the fleet against the patched stable releases referenced by the upstream commits
Monitor /proc/net/dev and ip link for MCTP interfaces that persist after teardown attempts
Enable CONFIG_DEBUG_KOBJECT_RELEASE and refcount debugging in test environments to surface leaked device references

Monitoring Recommendations

Collect kernel logs for unregister_netdevice: waiting for ... to become free messages on MCTP interfaces
Track long-term trends in kernel slab usage for net_device and related caches
Inventory hosts running MCTP workloads (typically BMC, OpenBMC, and platform management software) and prioritize them for patch validation

How to Mitigate CVE-2026-43455

Immediate Actions Required

Identify all systems running kernels that include MCTP routing code and verify whether the fix is applied
Apply the stable kernel updates that include the patches referenced in the upstream commits
Restrict local access to MCTP send paths on hosts that cannot be patched immediately

Patch Information

The fix takes key->lock around the key->dev check and the call to mctp_dev_set_key() in mctp_flow_prepare_output(), restoring the documented locking contract. The change is distributed across multiple stable trees in commits 0695712, 47893166, 7d86aa41, 86f5334f, 8d27d9b2, and 925a5ffd.

Workarounds

Disable the MCTP subsystem on hosts that do not require it by unloading or blacklisting the mctp modules
Limit which users and services can open MCTP sockets through standard Linux capability and namespace controls
Reboot affected hosts periodically to reclaim leaked references until patches are deployed

bash

# Verify whether the MCTP module is loaded and disable it where unused
lsmod | grep -E '^mctp'
sudo modprobe -r mctp
echo 'blacklist mctp' | sudo tee /etc/modprobe.d/disable-mctp.conf