CVE-2026-72125

HIGHCVSS 7.8/10EPSS 0.16%

Last modified

CVE-2026-72125 is a high-severity vulnerability rated 7.8/10 on the CVSS scale. 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. EPSS estimates a 0.16% chance of exploitation in the next 30 days.

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.

Metrics

CVSS 3.1
7.8/10

CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H

EPSS Probability
0.16%

5.6th percentile

Probability of exploitation in the next 30 days. Learn more

Affected Software

Source: CNA advisory (CVE.org). NVD analysis pending.

VendorProductVersions
LinuxLinux>= e057dd3fc20ffb3d7f150af46542a51b59b90127, < f311bbb29bb06aaab69ba45a6e4b11323d20b8f9; >= e057dd3fc20ffb3d7f150af46542a51b59b90127, < 8e018f4335590460ebcf0c2b493ed38ba1a35204; >= e057dd3fc20ffb3d7f150af46542a51b59b90127, < 33b9cd9245e2a4b800f99ed1cc53d64960614152; >= e057dd3fc20ffb3d7f150af46542a51b59b90127, < 0b811c4bbe3ec9ad611e90a540fe8b51b3bb8a96; >= e057dd3fc20ffb3d7f150af46542a51b59b90127, < 43884dc7963beef2328f507f4fe680bdc173eb80; >= e057dd3fc20ffb3d7f150af46542a51b59b90127, < 7bef39ba76eb7307ed22a50329e0f5776dbeda58; >= e057dd3fc20ffb3d7f150af46542a51b59b90127, < e442b62ba5a7756c17e05a77b32cdd085a2b6138; >= e057dd3fc20ffb3d7f150af46542a51b59b90127, < 20bab8b88baac140ca3701116e1d486c7f51e311
LinuxLinux5.10

References

Timeline

Published
Last Modified
Status
Received

Frequently Asked Questions

What is CVE-2026-72125?
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.
How severe is CVE-2026-72125?
CVE-2026-72125 has a CVSS score of 7.8/10 (HIGH severity). The EPSS model estimates a 0.16% probability of exploitation in the next 30 days.
How do I fix CVE-2026-72125?
Check the vendor references and advisories linked above for patched versions and mitigation guidance. You can also run a Strix scan to test if your systems are affected.

How Strix Helps

Related CVEs from 2026

Are you affected by CVE-2026-72125?

Run a free Strix scan to check your systems for this vulnerability.

Scan your code now

Source: NVD / NIST