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

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

[Greg Kroah-Hartman]

From: Greg Kroah-Hartman <gregkh@kernel.org>

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.

The Linux kernel CVE team has assigned CVE-2026-72125 to this issue.


Affected and fixed versions
===========================

	Issue introduced in 5.10 with commit e057dd3fc20ffb3d7f150af46542a51b59b90127 and fixed in 6.6.148 with commit 0b811c4bbe3ec9ad611e90a540fe8b51b3bb8a96
	Issue introduced in 5.10 with commit e057dd3fc20ffb3d7f150af46542a51b59b90127 and fixed in 6.12.101 with commit 43884dc7963beef2328f507f4fe680bdc173eb80
	Issue introduced in 5.10 with commit e057dd3fc20ffb3d7f150af46542a51b59b90127 and fixed in 6.18.40 with commit 7bef39ba76eb7307ed22a50329e0f5776dbeda58
	Issue introduced in 5.10 with commit e057dd3fc20ffb3d7f150af46542a51b59b90127 and fixed in 7.1.5 with commit e442b62ba5a7756c17e05a77b32cdd085a2b6138
	Issue introduced in 5.10 with commit e057dd3fc20ffb3d7f150af46542a51b59b90127 and fixed in 7.2-rc4 with commit 20bab8b88baac140ca3701116e1d486c7f51e311

Please see https://www.kernel.org for a full list of currently supported
kernel versions by the kernel community.

Unaffected versions might change over time as fixes are backported to
older supported kernel versions.  The official CVE entry at
	https://cve.org/CVERecord/?id=CVE-2026-72125
will be updated if fixes are backported, please check that for the most
up to date information about this issue.


Affected files
==============

The file(s) affected by this issue are:
	net/can/isotp.c


Mitigation
==========

The Linux kernel CVE team recommends that you update to the latest
stable kernel version for this, and many other bugfixes.  Individual
changes are never tested alone, but rather are part of a larger kernel
release.  Cherry-picking individual commits is not recommended or
supported by the Linux kernel community at all.  If however, updating to
the latest release is impossible, the individual changes to resolve this
issue can be found at these commits:
	https://git.kernel.org/stable/c/0b811c4bbe3ec9ad611e90a540fe8b51b3bb8a96
	https://git.kernel.org/stable/c/43884dc7963beef2328f507f4fe680bdc173eb80
	https://git.kernel.org/stable/c/7bef39ba76eb7307ed22a50329e0f5776dbeda58
	https://git.kernel.org/stable/c/e442b62ba5a7756c17e05a77b32cdd085a2b6138
	https://git.kernel.org/stable/c/20bab8b88baac140ca3701116e1d486c7f51e311