CVE-2026-43455

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> mctp: route: hold key-&gt;lock in mctp_flow_prepare_output()<br /> <br /> mctp_flow_prepare_output() checks key-&gt;dev and may call<br /> mctp_dev_set_key(), but it does not hold key-&gt;lock while doing so.<br /> <br /> mctp_dev_set_key() and mctp_dev_release_key() are annotated with<br /> __must_hold(&amp;key-&gt;lock), so key-&gt;dev access is intended to be<br /> serialized by key-&gt;lock. The mctp_sendmsg() transmit path reaches<br /> mctp_flow_prepare_output() via mctp_local_output() -&gt; mctp_dst_output()<br /> without holding key-&gt;lock, so the check-and-set sequence is racy.<br /> <br /> Example interleaving:<br /> <br /> CPU0 CPU1<br /> ---- ----<br /> mctp_flow_prepare_output(key, devA)<br /> if (!key-&gt;dev) // sees NULL<br /> mctp_flow_prepare_output(<br /> key, devB)<br /> if (!key-&gt;dev) // still NULL<br /> mctp_dev_set_key(devB, key)<br /> mctp_dev_hold(devB)<br /> key-&gt;dev = devB<br /> mctp_dev_set_key(devA, key)<br /> mctp_dev_hold(devA)<br /> key-&gt;dev = devA // overwrites devB<br /> <br /> Now both devA and devB references were acquired, but only the final<br /> key-&gt;dev value is tracked for release. One reference can be lost,<br /> causing a resource leak as mctp_dev_release_key() would only decrease<br /> the reference on one dev.<br /> <br /> Fix by taking key-&gt;lock around the key-&gt;dev check and<br /> mctp_dev_set_key() call.