fkie_cve-2025-22111
Vulnerability from fkie_nvd
Published
2025-04-16 15:16
Modified
2025-04-17 20:22
Severity ?
Summary
In the Linux kernel, the following vulnerability has been resolved: net: Remove RTNL dance for SIOCBRADDIF and SIOCBRDELIF. SIOCBRDELIF is passed to dev_ioctl() first and later forwarded to br_ioctl_call(), which causes unnecessary RTNL dance and the splat below [0] under RTNL pressure. Let's say Thread A is trying to detach a device from a bridge and Thread B is trying to remove the bridge. In dev_ioctl(), Thread A bumps the bridge device's refcnt by netdev_hold() and releases RTNL because the following br_ioctl_call() also re-acquires RTNL. In the race window, Thread B could acquire RTNL and try to remove the bridge device. Then, rtnl_unlock() by Thread B will release RTNL and wait for netdev_put() by Thread A. Thread A, however, must hold RTNL after the unlock in dev_ifsioc(), which may take long under RTNL pressure, resulting in the splat by Thread B. Thread A (SIOCBRDELIF) Thread B (SIOCBRDELBR) ---------------------- ---------------------- sock_ioctl sock_ioctl `- sock_do_ioctl `- br_ioctl_call `- dev_ioctl `- br_ioctl_stub |- rtnl_lock | |- dev_ifsioc ' ' |- dev = __dev_get_by_name(...) |- netdev_hold(dev, ...) . / |- rtnl_unlock ------. | | |- br_ioctl_call `---> |- rtnl_lock Race | | `- br_ioctl_stub |- br_del_bridge Window | | | |- dev = __dev_get_by_name(...) | | | May take long | `- br_dev_delete(dev, ...) | | | under RTNL pressure | `- unregister_netdevice_queue(dev, ...) | | | | `- rtnl_unlock \ | |- rtnl_lock <-' `- netdev_run_todo | |- ... `- netdev_run_todo | `- rtnl_unlock |- __rtnl_unlock | |- netdev_wait_allrefs_any |- netdev_put(dev, ...) <----------------' Wait refcnt decrement and log splat below To avoid blocking SIOCBRDELBR unnecessarily, let's not call dev_ioctl() for SIOCBRADDIF and SIOCBRDELIF. In the dev_ioctl() path, we do the following: 1. Copy struct ifreq by get_user_ifreq in sock_do_ioctl() 2. Check CAP_NET_ADMIN in dev_ioctl() 3. Call dev_load() in dev_ioctl() 4. Fetch the master dev from ifr.ifr_name in dev_ifsioc() 3. can be done by request_module() in br_ioctl_call(), so we move 1., 2., and 4. to br_ioctl_stub(). Note that 2. is also checked later in add_del_if(), but it's better performed before RTNL. SIOCBRADDIF and SIOCBRDELIF have been processed in dev_ioctl() since the pre-git era, and there seems to be no specific reason to process them there. [0]: unregister_netdevice: waiting for wpan3 to become free. Usage count = 2 ref_tracker: wpan3@ffff8880662d8608 has 1/1 users at __netdev_tracker_alloc include/linux/netdevice.h:4282 [inline] netdev_hold include/linux/netdevice.h:4311 [inline] dev_ifsioc+0xc6a/0x1160 net/core/dev_ioctl.c:624 dev_ioctl+0x255/0x10c0 net/core/dev_ioctl.c:826 sock_do_ioctl+0x1ca/0x260 net/socket.c:1213 sock_ioctl+0x23a/0x6c0 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] __x64_sys_ioctl+0x1a4/0x210 fs/ioctl.c:892 do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0xcb/0x250 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x77/0x7f
Impacted products
Vendor Product Version



{
  "cveTags": [],
  "descriptions": [
    {
      "lang": "en",
      "value": "In the Linux kernel, the following vulnerability has been resolved:\n\nnet: Remove RTNL dance for SIOCBRADDIF and SIOCBRDELIF.\n\nSIOCBRDELIF is passed to dev_ioctl() first and later forwarded to\nbr_ioctl_call(), which causes unnecessary RTNL dance and the splat\nbelow [0] under RTNL pressure.\n\nLet\u0027s say Thread A is trying to detach a device from a bridge and\nThread B is trying to remove the bridge.\n\nIn dev_ioctl(), Thread A bumps the bridge device\u0027s refcnt by\nnetdev_hold() and releases RTNL because the following br_ioctl_call()\nalso re-acquires RTNL.\n\nIn the race window, Thread B could acquire RTNL and try to remove\nthe bridge device.  Then, rtnl_unlock() by Thread B will release RTNL\nand wait for netdev_put() by Thread A.\n\nThread A, however, must hold RTNL after the unlock in dev_ifsioc(),\nwhich may take long under RTNL pressure, resulting in the splat by\nThread B.\n\n  Thread A (SIOCBRDELIF)           Thread B (SIOCBRDELBR)\n  ----------------------           ----------------------\n  sock_ioctl                       sock_ioctl\n  `- sock_do_ioctl                 `- br_ioctl_call\n     `- dev_ioctl                     `- br_ioctl_stub\n        |- rtnl_lock                     |\n        |- dev_ifsioc                    \u0027\n        \u0027  |- dev = __dev_get_by_name(...)\n           |- netdev_hold(dev, ...)      .\n       /   |- rtnl_unlock  ------.       |\n       |   |- br_ioctl_call       `---\u003e  |- rtnl_lock\n  Race |   |  `- br_ioctl_stub           |- br_del_bridge\n  Window   |     |                       |  |- dev = __dev_get_by_name(...)\n       |   |     |  May take long        |  `- br_dev_delete(dev, ...)\n       |   |     |  under RTNL pressure  |     `- unregister_netdevice_queue(dev, ...)\n       |   |     |               |       `- rtnl_unlock\n       \\   |     |- rtnl_lock  \u003c-\u0027          `- netdev_run_todo\n           |     |- ...                        `- netdev_run_todo\n           |     `- rtnl_unlock                   |- __rtnl_unlock\n           |                                      |- netdev_wait_allrefs_any\n           |- netdev_put(dev, ...)  \u003c----------------\u0027\n                                                Wait refcnt decrement\n                                                and log splat below\n\nTo avoid blocking SIOCBRDELBR unnecessarily, let\u0027s not call\ndev_ioctl() for SIOCBRADDIF and SIOCBRDELIF.\n\nIn the dev_ioctl() path, we do the following:\n\n  1. Copy struct ifreq by get_user_ifreq in sock_do_ioctl()\n  2. Check CAP_NET_ADMIN in dev_ioctl()\n  3. Call dev_load() in dev_ioctl()\n  4. Fetch the master dev from ifr.ifr_name in dev_ifsioc()\n\n3. can be done by request_module() in br_ioctl_call(), so we move\n1., 2., and 4. to br_ioctl_stub().\n\nNote that 2. is also checked later in add_del_if(), but it\u0027s better\nperformed before RTNL.\n\nSIOCBRADDIF and SIOCBRDELIF have been processed in dev_ioctl() since\nthe pre-git era, and there seems to be no specific reason to process\nthem there.\n\n[0]:\nunregister_netdevice: waiting for wpan3 to become free. Usage count = 2\nref_tracker: wpan3@ffff8880662d8608 has 1/1 users at\n     __netdev_tracker_alloc include/linux/netdevice.h:4282 [inline]\n     netdev_hold include/linux/netdevice.h:4311 [inline]\n     dev_ifsioc+0xc6a/0x1160 net/core/dev_ioctl.c:624\n     dev_ioctl+0x255/0x10c0 net/core/dev_ioctl.c:826\n     sock_do_ioctl+0x1ca/0x260 net/socket.c:1213\n     sock_ioctl+0x23a/0x6c0 net/socket.c:1318\n     vfs_ioctl fs/ioctl.c:51 [inline]\n     __do_sys_ioctl fs/ioctl.c:906 [inline]\n     __se_sys_ioctl fs/ioctl.c:892 [inline]\n     __x64_sys_ioctl+0x1a4/0x210 fs/ioctl.c:892\n     do_syscall_x64 arch/x86/entry/common.c:52 [inline]\n     do_syscall_64+0xcb/0x250 arch/x86/entry/common.c:83\n     entry_SYSCALL_64_after_hwframe+0x77/0x7f"
    },
    {
      "lang": "es",
      "value": "En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: net: Eliminaci\u00f3n del movimiento RTNL para SIOCBRADDIF y SIOCBRDELIF. SIOCBRDELIF se pasa primero a dev_ioctl() y luego a br_ioctl_call(), lo que provoca un movimiento RTNL innecesario y el splat debajo de [0] bajo presi\u00f3n RTNL. Supongamos que el subproceso A intenta desconectar un dispositivo de un puente y el subproceso B intenta eliminar el puente. En dev_ioctl(), el subproceso A aumenta el refcnt del dispositivo puente mediante netdev_hold() y libera RTNL porque el subproceso br_ioctl_call() tambi\u00e9n vuelve a adquirir RTNL. En la ventana de ejecuci\u00f3n, el subproceso B podr\u00eda adquirir RTNL e intentar eliminar el dispositivo puente. Luego, rtnl_unlock() del subproceso B liberar\u00e1 RTNL y esperar\u00e1 a netdev_put() del subproceso A. Sin embargo, el subproceso A debe mantener RTNL despu\u00e9s del desbloqueo en dev_ifsioc(), lo que puede tardar mucho bajo la presi\u00f3n de RTNL, lo que resulta en el splat del subproceso B. Subproceso A (SIOCBRDELIF) Subproceso B (SIOCBRDELBR) ---------------------- ---------------------- sock_ioctl sock_ioctl `- sock_do_ioctl `- br_ioctl_call `- dev_ioctl `- br_ioctl_stub |- rtnl_lock | |- dev_ifsioc \u0027 \u0027 |- dev = __dev_get_by_name(...) |- netdev_hold(dev, ...) . / |- rtnl_unlock ------. | | |- br_ioctl_call `---\u0026gt; |- rtnl_lock Race | | `- br_ioctl_stub |- br_del_bridge Ventana | | | |- dev = __dev_get_by_name(...) | | | Puede tomar mucho tiempo | `- br_dev_delete(dev, ...) | | | bajo presi\u00f3n RTNL | `- unregister_netdevice_queue(dev, ...) | | | | `- rtnl_unlock \\ | |- rtnl_lock \u0026lt;-\u0027 `- netdev_run_todo | |- ... `- netdev_run_todo | `- rtnl_unlock |- __rtnl_unlock | |- netdev_wait_allrefs_any |- netdev_put(dev, ...) \u0026lt;----------------\u0027 Espere la disminuci\u00f3n de refcnt y registre splat a continuaci\u00f3n Para evitar bloquear SIOCBRDELBR innecesariamente, no llamemos a dev_ioctl() para SIOCBRADDIF y SIOCBRDELIF. En la ruta dev_ioctl(), hacemos lo siguiente: 1. Copiar struct ifreq por get_user_ifreq en sock_do_ioctl() 2. Verificar CAP_NET_ADMIN en dev_ioctl() 3. Llamar a dev_load() en dev_ioctl() 4. Obtener el dev maestro de ifr.ifr_name en dev_ifsioc() 3. se puede hacer por request_module() en br_ioctl_call(), por lo que movemos 1., 2. y 4. a br_ioctl_stub(). Tenga en cuenta que 2. tambi\u00e9n se verifica m\u00e1s adelante en add_del_if(), pero se realiza mejor antes de RTNL. SIOCBRADDIF y SIOCBRDELIF se han procesado en dev_ioctl() desde la era anterior a Git, y no parece haber una raz\u00f3n espec\u00edfica para procesarlos all\u00ed. [0]: unregister_netdevice: esperando a que wpan3 quede libre. Recuento de uso = 2 ref_tracker: wpan3@ffff8880662d8608 tiene 1/1 usuarios en __netdev_tracker_alloc include/linux/netdevice.h:4282 [en l\u00ednea] netdev_hold include/linux/netdevice.h:4311 [en l\u00ednea] dev_ifsioc+0xc6a/0x1160 net/core/dev_ioctl.c:624 dev_ioctl+0x255/0x10c0 net/core/dev_ioctl.c:826 sock_do_ioctl+0x1ca/0x260 net/socket.c:1213 sock_ioctl+0x23a/0x6c0 net/socket.c:1318 vfs_ioctl fs/ioctl.c:51 [en l\u00ednea] __do_sys_ioctl fs/ioctl.c:906 [en l\u00ednea] __se_sys_ioctl fs/ioctl.c:892 [en l\u00ednea] __x64_sys_ioctl+0x1a4/0x210 fs/ioctl.c:892 do_syscall_x64 arch/x86/entry/common.c:52 [en l\u00ednea] do_syscall_64+0xcb/0x250 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x77/0x7f"
    }
  ],
  "id": "CVE-2025-22111",
  "lastModified": "2025-04-17T20:22:16.240",
  "metrics": {},
  "published": "2025-04-16T15:16:05.347",
  "references": [
    {
      "source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
      "url": "https://git.kernel.org/stable/c/00fe0ac64efd1f5373b3dd9f1f84b19235371e39"
    },
    {
      "source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
      "url": "https://git.kernel.org/stable/c/ed3ba9b6e280e14cc3148c1b226ba453f02fa76c"
    }
  ],
  "sourceIdentifier": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
  "vulnStatus": "Awaiting Analysis"
}


Log in or create an account to share your comment.




Tags
Taxonomy of the tags.


Loading…

Loading…

Loading…

Sightings

Author Source Type Date

Nomenclature

  • Seen: The vulnerability was mentioned, discussed, or seen somewhere by the user.
  • Confirmed: The vulnerability is confirmed from an analyst perspective.
  • Exploited: This vulnerability was exploited and seen by the user reporting the sighting.
  • Patched: This vulnerability was successfully patched by the user reporting the sighting.
  • Not exploited: This vulnerability was not exploited or seen by the user reporting the sighting.
  • Not confirmed: The user expresses doubt about the veracity of the vulnerability.
  • Not patched: This vulnerability was not successfully patched by the user reporting the sighting.


Loading…

Loading…