CVE-2025-21701

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net: avoid race between device unregistration and ethnl ops<br /> <br /> The following trace can be seen if a device is being unregistered while<br /> its number of channels are being modified.<br /> <br /> DEBUG_LOCKS_WARN_ON(lock-&gt;magic != lock)<br /> WARNING: CPU: 3 PID: 3754 at kernel/locking/mutex.c:564 __mutex_lock+0xc8a/0x1120<br /> CPU: 3 UID: 0 PID: 3754 Comm: ethtool Not tainted 6.13.0-rc6+ #771<br /> RIP: 0010:__mutex_lock+0xc8a/0x1120<br /> Call Trace:<br /> <br /> ethtool_check_max_channel+0x1ea/0x880<br /> ethnl_set_channels+0x3c3/0xb10<br /> ethnl_default_set_doit+0x306/0x650<br /> genl_family_rcv_msg_doit+0x1e3/0x2c0<br /> genl_rcv_msg+0x432/0x6f0<br /> netlink_rcv_skb+0x13d/0x3b0<br /> genl_rcv+0x28/0x40<br /> netlink_unicast+0x42e/0x720<br /> netlink_sendmsg+0x765/0xc20<br /> __sys_sendto+0x3ac/0x420<br /> __x64_sys_sendto+0xe0/0x1c0<br /> do_syscall_64+0x95/0x180<br /> entry_SYSCALL_64_after_hwframe+0x76/0x7e<br /> <br /> This is because unregister_netdevice_many_notify might run before the<br /> rtnl lock section of ethnl operations, eg. set_channels in the above<br /> example. In this example the rss lock would be destroyed by the device<br /> unregistration path before being used again, but in general running<br /> ethnl operations while dismantle has started is not a good idea.<br /> <br /> Fix this by denying any operation on devices being unregistered. A check<br /> was already there in ethnl_ops_begin, but not wide enough.<br /> <br /> Note that the same issue cannot be seen on the ioctl version<br /> (__dev_ethtool) because the device reference is retrieved from within<br /> the rtnl lock section there. Once dismantle started, the net device is<br /> unlisted and no reference will be found.