CVE-2025-22111 is a vulnerability in the Linux kernel's network subsystem related to the handling of bridge device ioctl commands, specifically SIOCBRADDIF and SIOCBRDELIF. The issue arises from a race condition involving the RTNL (rtnetlink) lock, which is used to serialize network device operations. When a thread (Thread A) attempts to detach a device from a bridge using SIOCBRDELIF, it calls dev_ioctl(), which increments the reference count of the bridge device and releases the RTNL lock before calling br_ioctl_call(), which re-acquires the RTNL lock. Concurrently, another thread (Thread B) may try to remove the entire bridge device using SIOCBRDELBR. Due to the timing of lock releases and acquisitions, Thread B can acquire the RTNL lock and proceed to remove the bridge device while Thread A still holds a reference to it. This leads to a deadlock or a kernel panic (referred to as a "splat"), as Thread B waits for the reference count to drop while Thread A is blocked holding the RTNL lock. The root cause is unnecessary RTNL locking (the "RTNL dance") in dev_ioctl() for these specific ioctl commands, which was not required and introduced a race window. The fix involves removing the dev_ioctl() call for SIOCBRADDIF and SIOCBRDELIF, moving some preliminary checks (such as CAP_NET_ADMIN capability verification and device lookup) to an earlier stage (br_ioctl_stub()), and performing module loading in br_ioctl_call(). This change reduces the lock contention and eliminates the race condition. The vulnerability affects Linux kernel versions prior to the patch referenced by commit 893b195875340cb44b54c9db99e708145f1210e8 and was published on April 16, 2025. No known exploits are reported in the wild as of now, and no CVSS score has been assigned.

For European organizations, this vulnerability poses a risk primarily to systems running Linux kernels with network bridging enabled, such as routers, firewalls, virtualization hosts, and container platforms that rely on Linux bridges for network traffic management. Exploitation could lead to kernel panics or denial of service (DoS) conditions, causing network outages or service disruptions. This can impact critical infrastructure, cloud service providers, telecom operators, and enterprises that depend on Linux-based networking. While the vulnerability does not directly enable privilege escalation or remote code execution, the resulting DoS could be leveraged in targeted attacks to disrupt operations or as part of multi-stage attacks. Given the widespread use of Linux in European data centers and network equipment, the potential impact on availability is significant, especially in environments with high RTNL lock contention or heavy network device reconfiguration. The vulnerability requires local access and administrative privileges (CAP_NET_ADMIN) to exploit, limiting the attack surface to authorized users or attackers who have already compromised a system. However, insider threats or lateral movement within networks could leverage this flaw to cause service interruptions.

1. Apply the official Linux kernel patch that removes the unnecessary RTNL locking for SIOCBRADDIF and SIOCBRDELIF as referenced by commit 893b195875340cb44b54c9db99e708145f1210e8 or later stable kernel releases. 2. For organizations unable to immediately patch, limit administrative access to network device configuration commands requiring CAP_NET_ADMIN to trusted personnel only, reducing the risk of exploitation. 3. Monitor kernel logs for signs of RTNL lock contention, kernel panics, or "splat" messages related to unregister_netdevice waits, which may indicate attempted exploitation or triggering of this race condition. 4. Implement strict access controls and auditing on systems performing network bridging operations, especially in multi-tenant or virtualized environments. 5. Consider deploying kernel live patching solutions if available for your Linux distribution to apply the fix without downtime. 6. Review network device management automation scripts or orchestration tools to avoid concurrent conflicting bridge device operations that could exacerbate the race condition. 7. Maintain up-to-date backups and incident response plans to quickly recover from potential DoS incidents caused by this vulnerability.