CVE-2026-43455

In the Linux kernel, the following vulnerability has been resolved:

mctp: route: hold key->lock in mctpflowprepare_output()

mctpflowprepareoutput() checks key->dev and may call mctpdevsetkey(), but it does not hold key->lock while doing so.

mctpdevsetkey() and mctpdevreleasekey() are annotated with _musthold(&key->lock), so key->dev access is intended to be serialized by key->lock. The mctpsendmsg() transmit path reaches mctpflowprepareoutput() via mctplocaloutput() -> mctpdstoutput() without holding key->lock, so the check-and-set sequence is racy.

Example interleaving:

CPU0 CPU1 ---- ---- mctpflowprepareoutput(key, devA) if (!key->dev) // sees NULL mctpflowprepareoutput( key, devB) if (!key->dev) // still NULL mctpdevsetkey(devB, key) mctpdevhold(devB) key->dev = devB mctpdevsetkey(devA, key) mctpdevhold(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 mctpdevrelease_key() would only decrease the reference on one dev.

Fix by taking key->lock around the key->dev check and mctpdevset_key() call.