Medium 5.5Published May 8, 2026

CVE-2026-43455mctp: route: hold key->lock in mctp_flow_prepare_output()

Updated under an hour ago (Oct 27, 2026, 2:30 PM ET)

Does this affect you?

It affects Linux and 1 other product. Add what you run to find out whether that includes you.

No exploitation reported and no EPSS estimate yet.

Do this next

Start free and add your stack

Free account, 1 product

Every CVE for Linux

Exploited in the last 30 days

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: 5.5 MEDIUM (v3.1, NVD)CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
Weakness (CWE): Not given
Known exploited: Not in CISA's KEV catalog
EPSS (exploitation in the next 30 days): Not loaded for this CVE
Assigned by: Linux
NVD analysis: Analyzed
Record last updated: May 11, 2026
First seen by InfoSec Signals: Oct 9, 2026

Affected products

Affected products

Linux Linux linux:linux (from the name)	from 67737c457281dd199ceb9e31b6ba7efd3bfe566d before 47893166bc5611ee9a20de6b8d2933b2320fb772; 67737c457281dd199ceb9e31b6ba7efd3bfe566d builds before 86f5334fcb48a5b611c33364ab52ca684d0f6d91; from 67737c457281dd199ceb9e31b6ba7efd3bfe566d before 0695712f3a6f1a48915f95767cfb42077683dcdc; 67737c457281dd199ceb9e31b6ba7efd3bfe566d builds before 925a5ffd99cddd7a7e41d5ad120c7a2c6d50260f; 67737c457281dd199ceb9e31b6ba7efd3bfe566d builds before 8d27d9b260dd19c1b519e1a13de6448f9984e30e; 67737c457281dd199ceb9e31b6ba7efd3bfe566d builds before 7d86aa41c073c4e7eb75fd2e674f1fd8f289728a	CNA record
linux linux_kernel linux:linux_kernel	from 5.16 before 6.1.167; from 6.2 before 6.6.130; from 6.7 before 6.12.78; from 6.13 before 6.18.19; from 6.19 before 6.19.9; 7.0; 7.0; 7.0	NVD

References

References

https://git.kernel.org/stable/c/47893166bc5611ee9a20de6b8d2933b2320fb772	patch
https://git.kernel.org/stable/c/86f5334fcb48a5b611c33364ab52ca684d0f6d91	patch
https://git.kernel.org/stable/c/0695712f3a6f1a48915f95767cfb42077683dcdc	patch
https://git.kernel.org/stable/c/925a5ffd99cddd7a7e41d5ad120c7a2c6d50260f	patch
https://git.kernel.org/stable/c/8d27d9b260dd19c1b519e1a13de6448f9984e30e	patch
https://git.kernel.org/stable/c/7d86aa41c073c4e7eb75fd2e674f1fd8f289728a	patch

The CVE record on cve.org NVD's entry

The CVE record is authoritative. Products marked “from the name” were identified from the CNA's free-text names, not a CPE, and are matched less certainly. This product uses the NVD API but is not endorsed or certified by the NVD.