net: Remove RTNL dance for SIOCBRADDIF and SIOCBRDELIF.
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 |
- Products
- Kernel
- Affected versions
- Not specified
- Fixed versions
- 5.15.198, 6.1.160, 6.12.65, 6.14.2, 6.6.120
- CVEs
- CVE-2025-22111
- Confirmed fixed CVEs
- Not specified
- Updated in this feed
- 4 Nov 2026, 16:13 UTC · Revision 1
Source evidence
net: Remove RTNL dance for SIOCBRADDIF and SIOCBRDELIF.
core-osv · Original sourcePublished 16 Apr 2025, 14:12 UTC
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 |
osv:CVE-2025-22111
Kernel
Fixed versions: 5.15.198, 6.1.160, 6.6.120, 6.12.65, 6.14.2
Complete source record
{
"id": "9f481505f5577f8afd94e37d72b9211a6177d069216cf28a8a518c97795e3448",
"url": "https://osv.dev/vulnerability/CVE-2025-22111",
"method": "structured",
"payload": {
"kind": "advisory",
"title": "net: Remove RTNL dance for SIOCBRADDIF and SIOCBRDELIF.",
"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 |",
"evidence": "osv:CVE-2025-22111",
"products": [
{
"name": {
"value": "Kernel",
"evidence": "/affected/1/package/name"
},
"prerequisites": [],
"fixed_versions": [
{
"value": "5.15.198",
"evidence": "/affected/1/ranges"
},
{
"value": "6.1.160",
"evidence": "/affected/1/ranges"
},
{
"value": "6.6.120",
"evidence": "/affected/1/ranges"
},
{
"value": "6.12.65",
"evidence": "/affected/1/ranges"
},
{
"value": "6.14.2",
"evidence": "/affected/1/ranges"
}
],
"affected_versions": []
}
],
"severity": "unknown",
"structured": {
"id": "CVE-2025-22111",
"aliases": [
"CVE-2025-22111"
],
"affected": [
{
"ranges": [
{
"repo": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git",
"type": "GIT",
"events": [
{
"introduced": "893b195875340cb44b54c9db99e708145f1210e8"
},
{
"fixed": "f51e471cb1577d510c3096e126678e1ea20d2efd"
},
{
"fixed": "338a0f3c66aef4ee13052880d02200aae8f2d8a8"
},
{
"fixed": "d767ce15045df510f55cdd2af5df0eee71f928d0"
},
{
"fixed": "4888e1dcc341e9a132ef7b8516234b3c3296de56"
},
{
"fixed": "00fe0ac64efd1f5373b3dd9f1f84b19235371e39"
},
{
"fixed": "ed3ba9b6e280e14cc3148c1b226ba453f02fa76c"
}
]
}
],
"database_specific": {
"source": "https://storage.googleapis.com/cve-osv-conversion/osv-output/CVE-2025-22111.json"
}
},
{
"ranges": [
{
"type": "ECOSYSTEM",
"events": [
{
"introduced": "5.15.0"
},
{
"fixed": "5.15.198"
}
]
},
{
"type": "ECOSYSTEM",
"events": [
{
"introduced": "5.16.0"
},
{
"fixed": "6.1.160"
}
]
},
{
"type": "ECOSYSTEM",
"events": [
{
"introduced": "6.2.0"
},
{
"fixed": "6.6.120"
}
]
},
{
"type": "ECOSYSTEM",
"events": [
{
"introduced": "6.7.0"
},
{
"fixed": "6.12.65"
}
]
},
{
"type": "ECOSYSTEM",
"events": [
{
"introduced": "6.13.0"
},
{
"fixed": "6.14.2"
}
]
}
],
"package": {
"name": "Kernel",
"ecosystem": "Linux"
},
"database_specific": {
"source": "https://storage.googleapis.com/cve-osv-conversion/osv-output/CVE-2025-22111.json"
}
}
],
"modified": "2026-10-28T02:30:37.235365583Z",
"provider": "osv",
"references": [
"https://cert-portal.siemens.com/productcert/html/ssa-019113.html",
"https://cert-portal.siemens.com/productcert/html/ssa-457936.html",
"https://git.kernel.org/stable/c/00fe0ac64efd1f5373b3dd9f1f84b19235371e39",
"https://git.kernel.org/stable/c/338a0f3c66aef4ee13052880d02200aae8f2d8a8",
"https://git.kernel.org/stable/c/4888e1dcc341e9a132ef7b8516234b3c3296de56",
"https://git.kernel.org/stable/c/d767ce15045df510f55cdd2af5df0eee71f928d0",
"https://git.kernel.org/stable/c/ed3ba9b6e280e14cc3148c1b226ba453f02fa76c",
"https://git.kernel.org/stable/c/f51e471cb1577d510c3096e126678e1ea20d2efd",
"https://github.com/CVEProject/cvelistV5/tree/main/cves/2025/22xxx/CVE-2025-22111.json",
"https://nvd.nist.gov/vuln/detail/CVE-2025-22111",
"https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git"
],
"provider_metadata": {
"cna_assigner": "Linux",
"osv_generated_from": "https://github.com/CVEProject/cvelistV5/tree/main/cves/2025/22xxx/CVE-2025-22111.json"
}
},
"related_cves": [
{
"value": "CVE-2025-22111",
"evidence": "/id"
}
],
"security_relevant": true,
"severity_evidence": null
},
"source_id": "core-osv",
"document_id": 504532,
"published_at": "2025-04-16T14:12:57.719+00:00"
}