CVE-2026-80995: net: mctp: hold a reference to the route device in mctp_route_lookup()
In the Linux kernel, the following vulnerability has been resolved:
net: mctp: hold a reference to the route device in mctproutelookup()
mctproutelookup() uses rt->dev without holding a reference on it. mctproutelookupsingle() returns the route under RCU only, so the route's device can be torn down concurrently: mctpdevput() drops the last reference and synchronously kfree()s mdev->addrs. mctpdevsaddr() then reads rt->dev->addrs[0], giving a use-after-free reachable by an unprivileged local AFMCTP user on the receive/forwarding path (no CAPNETRAW required):
BUG: KASAN: slab-use-after-free in mctproutelookup Read of size 1 at addr ... by task mctpuaf/... mctproutelookup mctppkttypereceive Freed by task ...: kfree mctpdevput mctpdevnotify
In the same window mctpdstfromroute() -> mctpdevhold() also increments a refcount that has already reached zero ("refcountt: addition on 0 ... mctpdevhold").
This reintroduces the use-after-free class of CVE-2023-3439: the source address lookup was moved ahead of the point where the destination takes its device reference.
Take a reference with refcountincnotzero() before touching rt->dev, skip a device that is already dead, and drop the reference once the destination has taken its own.
Affected Software
Event History
Frequently Asked Questions
Who can trigger the issue?
An unprivileged local user of AF_MCTP can reach the vulnerable receive or forwarding path. CAP_NET_RAW is not required.
What race is required for exploitation?
The route device must be torn down concurrently with route lookup. The failure occurs when the device's last reference is dropped and its address data is freed while the lookup path still accesses it.
What signs may indicate the race has occurred?
KASAN may report a slab use-after-free in mctp_route_lookup, with the access occurring through mctp_pkttype_receive. The kernel may also report a refcount increment on zero from mctp_dev_hold.