CVE-2026-72125 can: isotp: fix use-after-free race with concurrent NETDEV_UNREGISTER

High 7.8 Published Updated

A race condition in the Linux kernel CAN ISO-TP protocol allows a use-after-free, potentially leading to code execution or system crashes.

Exploited in the wild
Not known
Login needed
Any signed-in user
Attackable
Local or same network only
Victim action needed
Not needed
Fix
Available

What is CVE-2026-72125?

CVE-2026-72125 is a high-severity use after free vulnerability in Linux, published on 15 Aug 2026. It can only be exploited from the same machine or local network, with no action from the victim.

Official description

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

can: isotp: fix use-after-free race with concurrent NETDEV_UNREGISTER

isotp_release() looked up the bound network device via dev_get_by_index() using the stored ifindex. During device unregistration the device is unlisted from the ifindex hash before the NETDEV_UNREGISTER notifier chain runs, so a concurrent isotp_release() could find no device, skip can_rx_unregister() entirely, and still proceed to free the socket. Since isotp_release() had already removed itself from the isotp notifier list at that point, isotp_notify() would never get a chance to clean up either, leaving a stale CAN filter that keeps pointing at the freed socket.

Fix this the same way raw.c already does: hold a tracked reference to the bound net_device in the socket (so->dev/so->dev_tracker) from bind() onward instead of re-resolving it from the ifindex, and serialize bind()/release() with rtnl_lock() so that so->dev is always consistent with what the NETDEV_UNREGISTER notifier sees. so->dev stays valid regardless of ifindex-hash unlisting, and is only ever cleared by whichever of isotp_release()/isotp_notify() gets there first, so the filter is always removed exactly once.

isotp_bind() now rejects a (re)bind with -EAGAIN while so->[tx|rx].state isn't ISOTP_IDLE yet, so a timer left running by a prior NETDEV_UNREGISTER can't act on a newly bound so->ifindex. Both checks share the same lock_sock() section, so there is no window in which a concurrent isotp_notify() clearing so->bound could be missed.

Which versions are affected by CVE-2026-72125?

How do I fix CVE-2026-72125?

Apply the vendor's patch.

Upgrade to the fixed version. These bugs are found with fuzzing and sanitisers and avoided by memory-safe languages. More about Use after free.

Is CVE-2026-72125 being exploited?

There is no known exploitation of CVE-2026-72125 in the wild and no public exploit code.

Sources

Also known as BELL-CVE-2026-72125, DEBIAN-CVE-2026-72125, GHSA-37fw-xv85-q5fg, UBUNTU-CVE-2026-72125.

Is CVE-2026-72125 in your software?

Upload an SBOM and sbomify checks it against every vulnerability here, every day.

Check your SBOMs for free