CVE-2026-90093: Bluetooth: L2CAP: access chan->conn safely in get/setsockopt
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") l2capchan::conn has held reference and remains non-NULL also after the corresponding hciconn is deleted. In this state accessing various fields eg. hciconn::hdev is invalid, which leads to KASAN crash in l2capsocksetsockopt() access of conn->hcon->hdev.
Check l2capchan::conn.hcon corresponds to an alive hciconn before trying to use it in l2capsock.c. Hold l2capchanlock() in getsockopt/setsockopt to ensure it stays alive, and to avoid data races in l2capchan fields.
Affected Software
Event History
Frequently Asked Questions
What condition triggers the invalid access?
The condition occurs after the corresponding HCI connection has been deleted while the L2CAP channel still retains a non-NULL connection reference. Accessing fields beneath that retained reference, such as hci_conn::hdev, is then invalid.
Which socket operations are involved?
Both L2CAP getsockopt and setsockopt paths require protection. The reported KASAN crash occurs in l2cap_sock_setsockopt() when it accesses conn->hcon->hdev.
Is checking whether the L2CAP connection pointer is NULL sufficient?
No. The channel connection reference can remain non-NULL after its corresponding HCI connection has been deleted, so the associated HCI connection must be confirmed alive before its fields are used.
What does the fix do to prevent the race?
It holds l2cap_chan_lock() during getsockopt and setsockopt operations, ensuring the relevant channel state remains alive while accessed and preventing races in L2CAP channel fields.