CVE-2026-43455

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.