No kernel Linux, a seguinte vulnerabilidade foi resolvida: net: Remover dança RTNL para SIOCBRADDIF e SIOCBRDERDELIF. SIOCBRDELIF é passado para dev_ioctl() primeiro e mais tarde encaminhado para br_ioctl_call(), o que causa dança RTNL desnecessária e a dilatação abaixo [ 0 ] sob pressão RTNL. Digamos que o Thread A está tentando separar um dispositivo de uma ponte e o Thread B está tentando remover a ponte. No dev_ioctl(), Thread A bloqueia o refcnt do dispositivo da ponte por netdev_hold() e libera RTNL porque o seguinte br_ioctl_call() também reaquire RTNL. Na janela de corrida, o Thread B pode adquirir RTNL e tentar remover o dispositivo da ponte. Em seguida, rtnl_ unlock() por Thread B irá liberar RTNL e esperar pelo netdev_put() por Thread A. O Thread A, no entanto, deve segurar o RTNL após a desbloqueio em dev_ifsioc(), o que pode demorar muito sob pressão do RTNL, resultando na dilatação do Thread B. Thread A (SIOCBRDELIF) Thread B (SIOCBRDELBR) ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- decrement e log splat abaixo Para evitar bloquear SIOCBRDELBR desnecessariamente, não chamemos dev_ioctl() para SIOCBRADDIF e SIOCBRDELIF. No caminho dev_ioctl(), fazemos o seguinte: 1. Copiar o struct ifreq por get_user_ ifreq em sock_do_ioctl() 2. Verifique CAP_NET_ADMIN no dev_ioctl() 3. Chame dev_load() em dev_ioctl() 4. Obtenha o dev mestre de ifr.ifr_name em dev_ifsioc() 3. pode ser feito por request_module() em br_ioctl_call(), então nos movemos 1., 2., e 4. para br_ioctl_stub(). Note que 2. também é verificado mais tarde no add_del_if(), mas é melhor executado antes do RTNL. SIOCBRADDIF e SIOCBRDERDELIF foram processados em dev_ioctl() desde a era pré-git, e parece não haver nenhuma razão específica para processá-los lá. [ 0 ]: unregister_ netdevice: esperando pelo wpan 3 para se tornar livre. Contagem de uso = 2 ref_ tracker: wpan 3 @ffff 8880662 d 8608 tem 1 / 1 usuários em __netdev_tracker_alloc incluem/linux/netdevice.h: 4282 [inline] netdev_hold include/linux/netdevice.h: 4311 [inline] dev_ifsioc+ 0 xc 6 a/ 0 x 1160 líquido/core/dev_ioctl.c: 624 dev_ioctl+ 0 x 255 / 0 x 10 c 0 líquido/core/dev_ioctl.c: 826 Sock_do_ioctl+ 0 x 1 ca/ 0 x 260 net/ socket. c: 1213 sock_ioctl+ 0 x 23 a/ 0 x 6 c 0 net/ socket. c: 1318 vfs_ioctl fs/ioctl.c: 51 [inline] __do_sys_ioctl fs/ioctl.c: 906 [inline] __ se_sys_ioctl fs/ioctl.c: 892 [inline] __x 64 _sys_ioctl+ 0 x 1 a 4 / 0 x 210 fs/ ioctl.c: 892 do_syscall_x 64 arch/ x 86 /entry/common.c: 52 [inline] do_syscall_ 64 + 0 xcb/ 0 x 250 arch/ x 86 /entry/common.c: 83 digitação_SISCO_ 64 _após_hwframe+ 0 x 77 / 0 x 7 f.
O registro de base de dados de vulnerabilidade nacional CVE- 2025 - 22111 foi publicado em 2025 - 04 - 16 T 15: 16: 05.347 Z e última modificação em 2026 - 07 - 14 T 13: 17: 31.400 Z. O seu estado registrado é modificado.
métricas de vulnerabilidade gravadas: CVSS 3.1, pontuação de base 5.5, gravidade MEDIUM, vetor CVSS: 3.1 /AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H, pontuação de exploração 1.8, pontuação de impacto 3.6.
Classificações de fraqueza associadas: NVD- CWE- noinfo.
Os produtos ou plataformas nomeados nos dados de aplicabilidade incluem: kernel linux linux.
O registro NVD inclui referências de suporte documentando a vulnerabilidade, tecnologia afetada ou informações de remediação.