CVE-2025-21701 in Linux
Sumário
de VulDB • 25/05/2026
No kernel do Linux, a seguinte vulnerabilidade foi resolvida:
net: evitar condição de corrida entre o desregistro do dispositivo e as operações ethnl
O seguinte rastreamento pode ser observado se um dispositivo estiver sendo desregistrado enquanto seu número de canais está sendo modificado.
DEBUG_LOCKS_WARN_ON(lock->magic != lock) WARNING: CPU: 3 PID: 3754 at kernel/locking/mutex.c:564 __mutex_lock+0xc8a/0x1120 CPU: 3 UID: 0 PID: 3754 Comm: ethtool Not tainted 6.13.0-rc6+ #771 RIP: 0010:__mutex_lock+0xc8a/0x1120 Call Trace: ethtool_check_max_channel+0x1ea/0x880 ethnl_set_channels+0x3c3/0xb10 ethnl_default_set_doit+0x306/0x650 genl_family_rcv_msg_doit+0x1e3/0x2c0 genl_rcv_msg+0x432/0x6f0 netlink_rcv_skb+0x13d/0x3b0 genl_rcv+0x28/0x40 netlink_unicast+0x42e/0x720 netlink_sendmsg+0x765/0xc20 __sys_sendto+0x3ac/0x420 __x64_sys_sendto+0xe0/0x1c0 do_syscall_64+0x95/0x180 entry_SYSCALL_64_after_hwframe+0x76/0x7e
Isso ocorre porque unregister_netdevice_many_notify pode ser executado antes da seção de bloqueio rtnl das operações ethnl, por exemplo, set_channels no exemplo acima. Neste exemplo, o bloqueio rss seria destruído pelo caminho de desregistro do dispositivo antes de ser usado novamente, mas, em geral, executar operações ethnl enquanto a desmontagem (dismantle) começou não é uma boa ideia.
Corrija isso negando qualquer operação em dispositivos que estão sendo desregistrados. Uma verificação já existia em ethnl_ops_begin, mas não era abrangente o suficiente.
Observe que o mesmo problema não pode ser visto na versão ioctl (__dev_ethtool) porque a referência do dispositivo é recuperada dentro da seção de bloqueio rtnl lá. Uma vez iniciada a desmontagem, o dispositivo de rede é removido da lista e nenhuma referência será encontrada.
VulDB is the best source for vulnerability data and more expert information about this specific topic.