CVE-2026-43455
Received Received - Intake
Race Condition in Linux Kernel MCTP Routing

Publication date: 2026-05-08

Last updated on: 2026-05-08

Assigner: kernel.org

Description
In the Linux kernel, the following vulnerability has been resolved: mctp: route: hold key->lock in mctp_flow_prepare_output() mctp_flow_prepare_output() checks key->dev and may call mctp_dev_set_key(), but it does not hold key->lock while doing so. mctp_dev_set_key() and mctp_dev_release_key() are annotated with __must_hold(&key->lock), so key->dev access is intended to be serialized by key->lock. The mctp_sendmsg() transmit path reaches mctp_flow_prepare_output() via mctp_local_output() -> mctp_dst_output() without holding key->lock, so the check-and-set sequence is racy. Example interleaving: CPU0 CPU1 ---- ---- mctp_flow_prepare_output(key, devA) if (!key->dev) // sees NULL mctp_flow_prepare_output( key, devB) if (!key->dev) // still NULL mctp_dev_set_key(devB, key) mctp_dev_hold(devB) key->dev = devB mctp_dev_set_key(devA, key) mctp_dev_hold(devA) key->dev = devA // overwrites devB Now both devA and devB references were acquired, but only the final key->dev value is tracked for release. One reference can be lost, causing a resource leak as mctp_dev_release_key() would only decrease the reference on one dev. Fix by taking key->lock around the key->dev check and mctp_dev_set_key() call.
CVSS Scores
EPSS Scores
Probability:
Percentile:
Meta Information
Published
2026-05-08
Last Modified
2026-05-08
Generated
2026-05-09
AI Q&A
2026-05-08
EPSS Evaluated
N/A
NVD
EUVD
Affected Vendors & Products
Showing 1 associated CPE
Vendor Product Version / Range
linux_kernel mctp *
Helpful Resources
Exploitability
CWE
CWE Icon
KEV
KEV Icon
CWE ID Description
CWE-UNKNOWN
Attack-Flow Graph
AI Powered Q&A
Can you explain this vulnerability to me?

This vulnerability exists in the Linux kernel's MCTP (Management Component Transport Protocol) implementation, specifically in the function mctp_flow_prepare_output(). The function checks the key->dev pointer and may call mctp_dev_set_key(), but it does not hold the key->lock while doing so.

Because mctp_dev_set_key() and mctp_dev_release_key() require the key->lock to be held to serialize access to key->dev, the lack of locking in mctp_flow_prepare_output() creates a race condition. This means that two CPUs can simultaneously check and set key->dev without proper synchronization.

An example interleaving shows that two different devices (devA and devB) can both acquire references, but only the last set device is tracked for release. This causes one reference to be lost, leading to a resource leak.

The fix involves taking the key->lock around the check of key->dev and the call to mctp_dev_set_key() to ensure proper serialization and prevent the race condition.


How can this vulnerability impact me? :

This vulnerability can lead to a resource leak in the Linux kernel's MCTP implementation. Specifically, because of the race condition, one device reference may be lost and not properly released.

Resource leaks can degrade system performance over time, potentially leading to exhaustion of kernel resources, instability, or crashes if the leak is severe or persistent.


What immediate steps should I take to mitigate this vulnerability?

The vulnerability is caused by a race condition in the Linux kernel's mctp module where key->lock is not held during certain operations, leading to potential resource leaks.

To mitigate this vulnerability immediately, you should update your Linux kernel to a version where this issue is fixed. The fix involves taking key->lock around the key->dev check and mctp_dev_set_key() call to prevent the race condition.


Ask Our AI Assistant
Need more information? Ask your question to get an AI reply (Powered by our expertise)
0/70
EPSS Chart