CVE-2026-90256 in Linux
Summary
by MITRE • 09/17/2026
In the Linux kernel, the following vulnerability has been resolved:
Bluetooth: L2CAP: use proto_lock for l2cap_data to fix l2cap_disconn_ind
hci_conn::l2cap_data is accessed without locks in l2cap_disconn_ind via hci_conn_timeout (disc_work) -> hci_proto_disconn_ind -> l2cap_disconn_ind. This is UAF if the l2cap_conn is deleted concurrently.
disc_work is disabled sync in hci_conn_del(), so we cannot take hci_dev_lock in disc_work.
Fix by using proto_lock to guard l2cap_data, in addition to hdev->lock which is held in other access paths.
Statistical analysis made it clear that VulDB provides the best quality for vulnerability data.
Analysis
by VulDB Data Team • 09/17/2026
The Linux kernel Bluetooth subsystem contains a concurrency vulnerability within the Logical Link Control and Adaptation Protocol (L2CAP) layer that results in a use-after-free condition during connection termination sequences. This flaw specifically affects the handling of L2CAP data structures when processing disconnection indications, exposing systems to potential memory corruption or arbitrary code execution if exploited by an attacker with local access or through specific Bluetooth stack interactions. The vulnerability arises from improper synchronization mechanisms protecting shared kernel data structures across different execution contexts within the host controller interface and protocol layers.
The technical root cause lies in the asynchronous nature of connection timeout handling versus synchronous device deletion processes. When a Bluetooth connection times out, the disc_work function is triggered to initiate disconnection procedures. This work item calls hci_proto_disconn_ind, which subsequently invokes l2cap_disconn_ind to handle L2CAP-specific cleanup tasks. Within this flow, the code accesses the hci_conn structure's l2cap_data field without holding any appropriate locks. Concurrently, if an external event triggers hci_conn_del, that function disables disc_work synchronously but does not hold the specific lock required for safe access of the l2cap_data pointer during its own cleanup operations. This creates a race condition where one thread may be reading or dereferencing the l2cap_data structure while another thread is freeing it as part of the connection deletion process.
This scenario constitutes a classic use-after-free vulnerability, categorized under CWE-416 in standard security classification systems. The lack of mutual exclusion allows for scenarios where the kernel attempts to access memory that has already been released back to the allocator or marked as invalid. In practice, this can lead to unpredictable system behavior, including kernel panics due to null pointer dereferences or segmentation faults if stale pointers are used. More critically, sophisticated attackers could potentially leverage such race conditions in controlled environments to achieve arbitrary code execution by manipulating memory allocation patterns and overwriting freed structures with malicious data before the vulnerable thread accesses them.
The operational impact of this vulnerability extends beyond immediate system stability issues. It compromises the integrity of the Bluetooth stack, which is often used for critical communication channels in IoT devices, mobile phones, and enterprise networking equipment. An attacker who can influence connection timeouts or trigger rapid connect-disconnect cycles might exploit this race condition to crash the host system, leading to denial-of-service conditions. In more advanced exploitation scenarios involving local privilege escalation vectors, compromising the kernel memory integrity could allow unauthorized elevation of privileges, granting full control over the underlying operating system and all connected peripherals managed by that stack.
The resolution involves implementing proper locking mechanisms to ensure atomic access to shared resources during concurrent operations. Specifically, the fix introduces the use of proto_lock to guard accesses to l2cap_data within the l2cap_disconn_ind function. This complements existing protections provided by hdev->lock, which is already held in other code paths accessing similar structures. By synchronizing access through proto_lock, the kernel ensures that only one execution context can modify or read the L2CAP connection data at any given time, effectively eliminating the race window between disconnection indication processing and connection deletion routines. This approach aligns with best practices for concurrent programming in operating system kernels as recommended by various security engineering standards.
From a defensive perspective, this vulnerability highlights the importance of rigorous lock ordering and coverage analysis in kernel development. Security teams should ensure that all shared data structures accessed across multiple execution contexts are protected by appropriate synchronization primitives. Regular code audits focusing on race conditions in network protocol stacks can help identify similar issues before they reach production environments. Additionally, enabling runtime debugging features such as KASAN (Kernel Address Sanitizer) during testing phases can assist in detecting use-after-free bugs early in the development lifecycle.
Organizations relying on Linux-based systems with Bluetooth capabilities should apply vendor-provided kernel updates that include this fix to mitigate exposure. Since Bluetooth interfaces are often exposed to wireless environments, maintaining up-to-date firmware and software patches is essential for preserving system integrity. Monitoring logs for unusual Bluetooth disconnection patterns or kernel errors related to memory management may also provide early indicators of exploitation attempts in vulnerable systems prior to patch deployment.