CVE-2026-43455

What it actually does

This is a local Linux kernel race condition in the MCTP transmit path. mctp_flow_prepare_output() checks and assigns key->dev without holding key->lock, allowing two concurrent send paths to observe an unset device pointer and each acquire a reference to a different MCTP device. Only the final key->dev value remains tracked, so one reference can be leaked. Repeated triggering can consume kernel resources and degrade or deny service. The vulnerability does not directly provide confidentiality or integrity impact and requires local privileges to exercise the affected kernel interface.

Why it matters to the business

A local user or compromised low-privilege process could destabilize systems that have Linux kernel MCTP support available, potentially causing resource exhaustion, service disruption, or host unavailability. The risk is primarily availability-focused. The issue is not currently listed in CISA KEV, is not known to be used in ransomware campaigns, has very low EPSS, and has no reported public exploit maturity, but kernel availability bugs should still be patched through normal operating-system maintenance because they can affect shared servers, appliances, and multi-user environments.

How an attack unfolds

An attacker first obtains the ability to run local code on a vulnerable Linux system where MCTP functionality is present and usable. They then create or use MCTP communication paths and issue concurrent send operations that reach mctp_sendmsg(), mctp_local_output(), mctp_dst_output(), and ultimately mctp_flow_prepare_output(). By racing two execution paths against the same flow key while targeting different MCTP devices, both paths can acquire device references before key->dev is consistently protected by key->lock. One reference is overwritten and no longer released. Repeating the race can leak kernel references and consume resources until the system experiences degraded networking behavior, memory pressure, hangs, or a denial-of-service condition.

How to fix it

Apply a Linux kernel update from the operating-system or appliance vendor that includes the fix to hold key->lock around the key->dev check and mctp_dev_set_key() call in mctp_flow_prepare_output(). No exact fixed package versions were provided in the input, so use the relevant vendor advisory for the distribution, kernel branch, or embedded platform. After updating, reboot into the fixed kernel. If immediate patching is not possible, reduce exposure by disabling or unloading MCTP support where it is not required, preventing untrusted users from running local code, limiting access to systems that expose MCTP functionality, and using host controls such as container isolation, seccomp/AppArmor/SELinux policy, and least-privilege access to reduce the ability of low-privilege processes to exercise uncommon kernel interfaces.

How to confirm the fix worked

Confirm the running kernel is the vendor-fixed build, not merely that packages were installed; verify with uname, package manager metadata, and reboot status. For source-based kernels, confirm the patch serializes mctp_flow_prepare_output() by taking key->lock around the key->dev check and mctp_dev_set_key() call. Confirm MCTP is disabled or unavailable if mitigation rather than patching is used. Review loaded modules and kernel configuration for MCTP support. In a lab only, stress-test MCTP send paths while monitoring kernel logs and resource usage to ensure the reference leak no longer reproduces.

Typical attack path

1. Gain local code execution or authenticated local access to a vulnerable Linux system.
2. Confirm MCTP kernel support is enabled or loadable and that the attacker can access the relevant local socket/interface path.
3. Create MCTP traffic flows that invoke the vulnerable transmit path.
4. Run concurrent send operations to race mctp_flow_prepare_output() against the same key while using different devices or routes.
5. Repeat the race to leak MCTP device references.
6. Drive cumulative resource exhaustion until the host or affected services become unstable or unavailable.

How to detect it

There is no reliable remote network indicator for this vulnerability because exploitation is local and causes a kernel resource leak rather than a distinctive payload. To assess possible prior exploitation, review kernel logs from journald, dmesg, syslog, crash dumps, and monitoring telemetry for unexplained availability degradation, OOM conditions, hung tasks, kernel warnings, or reboots that coincide with local processes using MCTP. Review auditd, eBPF, EDR, or syscall telemetry for unusual creation or use of AF_MCTP sockets, repeated sendmsg activity through MCTP paths, or unexpected loading of MCTP-related kernel modules. Correlate those events with user sessions, container workloads, cron jobs, and recently introduced binaries. Kernel crash traces referencing mctp_flow_prepare_output(), mctp_dst_output(), mctp_local_output(), mctp_sendmsg(), mctp_dev_set_key(), or mctp_dev_release_key() should be investigated, but absence of those strings does not rule out exploitation because the primary symptom may be silent reference leakage followed by resource exhaustion.

• mctp_flow_prepare_output
• mctp_dst_output
• mctp_local_output
• mctp_sendmsg
• mctp_dev_set_key
• mctp_dev_release_key
• AF_MCTP
• Address family not supported by protocol: MCTP
• Out of memory
• oom-killer
• Kernel panic
• hung task
• blocked for more than
• mctp

What your security team should do

• Prioritize patching Linux systems where untrusted users, containers, shared workloads, or third-party code can run locally.
• Identify systems with MCTP support enabled, loaded, or required by hardware management workflows; patch those first.
• If MCTP is not required, disable or block loading of the relevant MCTP kernel functionality until fixed kernels are deployed.
• Monitor kernel logs for MCTP-related warnings, resource exhaustion, OOM events, hangs, or unexpected reboots on systems where local users have shell or workload execution access.
• Correlate availability incidents with local process activity, especially unusual processes creating MCTP sockets or generating high-rate MCTP send activity.
• Track distribution and appliance vendor advisories for exact fixed kernel package versions because no fixed versions were supplied in the vulnerability metadata.