CVE-2026-90091 in Linux
Summary
by MITRE • 09/17/2026
In the Linux kernel, the following vulnerability has been resolved:
Bluetooth: L2CAP: fix race l2cap_sock_cleanup_listen() vs. put_chan
For L2CAP sockets without owning sk->sk_socket, reading l2cap_pi(sk)->chan may race against concurrent l2cap_sock_kill() -> l2cap_sock_put_chan(). This excludes simultaneous proto_ops callbacks, but access in l2cap_sock_cleanup_listen() has unsafe lockless read.
[Task 1] [Task 2 (hdev->workqueue)]
l2cap_sock_release(parent) l2cap_disconn_cfm l2cap_sock_cleanup_listen l2cap_conn_del bt_accept_dequeue l2cap_chan_del lock_sock(sk) l2cap_sock_teardown_cb bt_accept_unlink bt_sk(sk)->parent = NULL release_sock(sk) ----------------> lock_sock(sk) parent = /* NULL */ lock_sock(sk) <--------------------- release_sock(sk) sock_set_flag(sk, SOCK_ZAPPED) l2cap_sock_close_cb l2cap_sock_kill(sk) l2cap_sock_put_chan chan = READ l2cap_pi(sk)->chan l2cap_pi(sk)->chan = NULL l2cap_chan_hold_unless_zero l2cap_put_chan(chan) kref_get_unless_zero(&chan->ref)
Task 1 may observe NULL which causes null-ptr-deref.
Fix the race by taking lock_sock() in l2cap_sock_kill() to synchronize with l2cap_sock_cleanup_listen(). hold_unless_zero() is not needed here, l2cap_pi(sk)->chan owns reference if it is non-NULL.
Clarify code comments vs. locking.
If you want to get best quality of vulnerability data, you may have to visit VulDB.
Analysis
by VulDB Data Team • 09/17/2026
The Linux kernel Bluetooth subsystem contains a race condition within the Logical Link Control and Adaptation Protocol (L2CAP) implementation that can lead to a null pointer dereference during socket cleanup operations. This vulnerability specifically affects L2CAP sockets where the associated socket structure does not own its sk_socket member, creating an unsafe window for concurrent access to internal channel pointers. The core of the issue lies in the interaction between l2cap_sock_cleanup_listen and l2cap_sock_kill functions, which operate on different execution contexts but share critical state data without adequate synchronization mechanisms.
The technical flaw arises because l2cap_sock_cleanup_listen performs a lockless read of the l2cap_pi(sk)->chan pointer while another task may be concurrently executing l2cap_sock_kill through the hdev workqueue. In this scenario, Task 1 initiates socket release via l2cap_sock_release and subsequently calls l2cap_sock_cleanup listen to clean up listening sockets. Simultaneously, Task 2 processes a disconnection confirmation event which triggers l2cap_disconn_cfm leading to connection deletion and eventually calling l2cap_sock_kill. The race occurs when Task 1 reads the chan pointer after it has been set to NULL by Task 2 but before proper synchronization is established, resulting in a null pointer dereference if subsequent operations attempt to use this uninitialized reference.
This vulnerability maps directly to CWE-362 which describes concurrent access with insufficient synchronization as a common cause of race conditions leading to unpredictable behavior and potential denial of service or code execution depending on the context. The attack vector involves triggering simultaneous socket release and disconnection events, potentially through crafted Bluetooth connection attempts that exploit timing windows in the kernel's event handling subsystem. While the vulnerability excludes certain proto_ops callbacks due existing locking mechanisms, it specifically targets cleanup paths where lockless reads were previously deemed safe but are not under concurrent modification scenarios involving sock_kill operations.
The operational impact of this race condition is primarily a system crash or kernel panic resulting from the null pointer dereference when l2cap_sock_cleanup_listen attempts to access freed memory through the NULL chan pointer. This constitutes a denial of service vulnerability that can be triggered remotely by malicious Bluetooth devices capable of initiating rapid connection and disconnection sequences against vulnerable systems. The impact extends beyond simple crashes as it may expose kernel memory contents or allow for further exploitation if the null dereference occurs in a context where attacker-controlled data influences subsequent execution paths, though the primary documented risk remains system stability degradation through unpredictable termination of kernel processes handling Bluetooth connections.
The fix addresses this vulnerability by introducing lock_sock calls within l2cap_sock_kill to synchronize access with l2cap_sock_cleanup_listen ensuring that both functions operate under consistent locking conditions when accessing shared state. This synchronization prevents the window where Task 1 could observe a NULL chan pointer while Task 2 is in the process of nullifying it and releasing references. The solution also clarifies code comments regarding locking requirements to prevent future developers from introducing similar race conditions by removing unnecessary hold_unless_zero calls since l2cap_pi(sk)->chan already owns its reference when non-NULL, simplifying the logic while maintaining safety guarantees through proper mutex-based synchronization rather than lockless reads in critical sections.
Mitigation strategies for organizations running affected Linux kernel versions include applying upstream kernel patches that incorporate this fix as soon as they become available through distribution update channels. For systems where immediate patching is not feasible administrators should consider disabling Bluetooth services if not required or implementing network segmentation to restrict exposure of vulnerable hosts to untrusted wireless environments. Monitoring system logs for unexpected kernel panics related to L2CAP operations can help identify potential exploitation attempts in real time while maintaining strict access controls on Bluetooth configuration interfaces to prevent unauthorized modification that might exacerbate timing windows exploitable by attackers with local or physical proximity capabilities.