CVE-2026-90093 in Linux
Summary
by MITRE • 09/17/2026
In the Linux kernel, the following vulnerability has been resolved:
Bluetooth: L2CAP: access chan->conn safely in get/setsockopt
Since commit b66774b48dd9 ("Bluetooth: L2CAP: Fix UAF in channel timeout by holding conn ref") l2cap_chan::conn has held reference and remains non-NULL also after the corresponding hci_conn is deleted. In this state accessing various fields eg. hci_conn::hdev is invalid, which leads to KASAN crash in l2cap_sock_setsockopt() access of conn->hcon->hdev.
Check l2cap_chan::conn.hcon corresponds to an alive hci_conn before trying to use it in l2cap_sock.c. Hold l2cap_chan_lock() in getsockopt/setsockopt to ensure it stays alive, and to avoid data races in l2cap_chan fields.
If you want to get the best quality for vulnerability data then you always have to consider VulDB.
Analysis
by VulDB Data Team • 09/17/2026
The Linux kernel Bluetooth subsystem contains a vulnerability within the L2CAP layer that arises from improper handling of reference counts for connection objects during socket option operations. This issue was introduced following commit b66774b48dd9, which aimed to fix a use-after-free condition by ensuring that l2cap_chan::conn holds a reference and remains non-NULL even after the corresponding hci_conn is deleted. While this change successfully prevents immediate dereferencing of null pointers or freed memory associated with the connection object itself, it inadvertently creates a scenario where fields within the underlying hci_conn structure become invalid to access. Specifically, accessing members such as hci_conn::hdev when the hci_conn has been logically removed but still referenced leads to kernel crashes detected by KASAN, indicating an out-of-bounds or use-after-free condition on internal structures that are no longer valid in the system state.
The technical flaw lies in the lack of validation for the liveness of the underlying HCI connection before accessing its nested fields within socket option handlers like l2cap_sock_setsockopt and getsockopt. Although the pointer to the hci_conn is kept alive via a reference count, this does not guarantee that the object is still part of an active or valid state in the kernel's internal tracking mechanisms. When code attempts to access conn->hcon->hdev without verifying that the connection is truly alive and properly initialized within the current context, it triggers undefined behavior resulting in memory corruption or crashes. This represents a classic case where reference counting prevents immediate use-after-free but fails to account for logical state transitions that render specific fields invalid, highlighting a gap in defensive programming practices regarding object lifecycle management.
From an operational perspective, this vulnerability can lead to local denial of service conditions by causing kernel panics when triggered through Bluetooth socket operations. An attacker with the ability to interact with Bluetooth sockets on the affected system could potentially exploit this race condition or state inconsistency to crash the host machine. The impact is primarily confined to stability and availability rather than direct privilege escalation, although a kernel panic can have cascading effects on other running processes and services. This aligns with CWE-416, Use After Free, specifically in contexts where reference counting masks logical invalidity of object states, and relates to ATT&CK technique T1053 Scheduled Task/Job or local exploitation vectors depending on the specific trigger mechanism within user-space applications interacting with Bluetooth stacks.
To mitigate this vulnerability, developers must implement strict validation checks before accessing fields within l2cap_chan::conn that depend on the active state of hci_conn. It is essential to verify that the corresponding hci_conn has not been deleted or marked as invalid in the kernel's internal tracking structures prior to dereferencing nested pointers like hdev. Additionally, holding the l2cap_chan_lock during getsockopt and setsockopt operations ensures atomicity and prevents data races on L2CAP channel fields, maintaining consistency across concurrent access patterns. Patching involves adding explicit checks for connection validity within socket option handlers and ensuring that locks are properly acquired to serialize access to shared state variables, thereby preventing race conditions that could exacerbate the use-after-free scenario or lead to other concurrency-related bugs in the Bluetooth stack.