CVE-2026-72125
CVE CVE-2026-72125EUVD EUVD-2026-58883Published 2026-08-15T05:53:02.000ZLast changed 2026-08-19T16:36:23.000ZCVSS 7.8
What the advisory describes
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.
Source: EUVD (ENISA), in the words of the advisory.
Products the advisory names
These come from the advisory itself, not from any check we performed.
- Linux — Linux e057dd3fc20ffb3d7f150af46542a51b59b90127 <7bef39ba76eb7307ed22a50329e0f5776dbeda58; e057dd3fc20ffb3d7f150af46542a51b59b90127 <0b811c4bbe3ec9ad611e90a540fe8b51b3bb8a96; patch: 6.12.101; patch: 6.18.40; e057dd3fc20ffb3d7f150af46542a51b59b90127 <20bab8b88baac140ca3701116e1d486c7f51e311; e057dd3fc20ffb3d7f150af46542a51b59b90127 <33b9cd9245e2a4b800f99ed1cc53d64960614152; patch: 7.1.5; patch: 7.2; 5.10; patch: 6.6.148; e057dd3fc20ffb3d7f150af46542a51b59b90127 <43884dc7963beef2328f507f4fe680bdc173eb80; patch: 6.1.183; e057dd3fc20ffb3d7f150af46542a51b59b90127 <e442b62ba5a7756c17e05a77b32cdd085a2b6138; e057dd3fc20ffb3d7f150af46542a51b59b90127 <f311bbb29bb06aaab69ba45a6e4b11323d20b8f9; patch: 5.10.265; e057dd3fc20ffb3d7f150af46542a51b59b90127 <8e018f4335590460ebcf0c2b493ed38ba1a35204; patch: 0; patch: 5.15.216
The versions shown are the advisory's own. Patchlage compares no version numbers and derives no judgement from them — which version is installed is something a person has to look up.
Carried in the product catalogue
An estate covering these products can be recorded in Patchlage. An advisory about them appears in the next morning's situation report.
- Linux — Linux
Does this concern one of your customers?
This page cannot answer that — it does not know your estate. Whoever has recorded their environments gets the answer the morning after publication, together with a paragraph they can forward to the customer unedited.
Try it for 28 daysPatchlage reports hits and suspected hits. About everything else this system says nothing — neither this page nor the situation report ever claims that an estate is safe.