CVE-2026-72125

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

HIGH
7.8
CVSS Score
Published: August 15, 2026 at 05:53 AM UTC
Updated: October 16, 2026 at 07:17 PM UTC
1 product affected across 1 vendorLinux Kernel

Using Linux by Linux?

Get instant alerts when new vulnerabilities affect Linux - before attackers find them.

Real-time alertsTrack your software stackFree plan available
Severity
HIGH7.8
Exploit prediction
EPSS 0.2%
SSVC
No known exploit

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.

Affected

Our own answer: ranges merged, affected separated from platform-only, with confidence and review flags.

5.10e057dd3fc20ffb3d7f150af46542a51b59b90127
Vendor states this is fixed in 0b811c4bbe3ec9ad611e90a540fe8b51b3bb8a96 (fixed)
Vendor states this is fixed in 20bab8b88baac140ca3701116e1d486c7f51e311 (fixed)
Vendor states this is fixed in 33b9cd9245e2a4b800f99ed1cc53d64960614152 (fixed)
Vendor states this is fixed in 43884dc7963beef2328f507f4fe680bdc173eb80 (fixed)
Vendor states this is fixed in 7bef39ba76eb7307ed22a50329e0f5776dbeda58 (fixed)
Vendor states this is fixed in 8e018f4335590460ebcf0c2b493ed38ba1a35204 (fixed)
Vendor states this is fixed in e442b62ba5a7756c17e05a77b32cdd085a2b6138 (fixed)
Vendor states this is fixed in f311bbb29bb06aaab69ba45a6e4b11323d20b8f9 (fixed)
Vendor states this is fixed in 5.10 (unaffected)
Vendor states this is fixed in 5.10.265 (unaffected)
Vendor states this is fixed in 5.15.216 (unaffected)
Vendor states this is fixed in 6.1.183 (unaffected)
Vendor states this is fixed in 6.12.101 (unaffected)
Vendor states this is fixed in 6.18.40 (unaffected)
Vendor states this is fixed in 6.6.148 (unaffected)
Vendor states this is fixed in 7.1.5 (unaffected)
Vendor states this is fixed in 7.2 (unaffected)

Remediation

No guide yet

No remediation guidance has been written for this CVE yet, and no fixed version or vendor advisory is recorded against it.

SSVC — Action Prioritization

SSVCNo known exploitNot automatableTotal impact

SSVC signals action urgency (what to patch first), separate from CVSS which measures severity.

CVSS

7.8HIGHLinux
Vector?

Quick Info

StatusRECEIVED

Get alerted

Stop reading CVE feeds looking for your own stack

Track the products you run and VulnTracker tells you when a new CVE affects them — with what is known about fixing it, and nothing about the rest.

Free plan, no card