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
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Upgrade
Upgrade
linux/Kernelto a version that resolves this vulnerability.Fixed in 5.10.273 - Upgrade
Upgrade
linux/Kernelto a version that resolves this vulnerability.Fixed in 5.15.224 - Upgrade
Upgrade
linux/Kernelto a version that resolves this vulnerability.Fixed in 6.1.191 - Upgrade
Upgrade
linux/Kernelto a version that resolves this vulnerability.Fixed in 6.6.160 - Upgrade
Upgrade
linux/Kernelto a version that resolves this vulnerability.Fixed in 6.12.114 - Upgrade
Upgrade
linux/Kernelto a version that resolves this vulnerability.Fixed in 6.18.57 - Upgrade
Upgrade
linux/Kernelto a version that resolves this vulnerability.Fixed in 7.2.6 - Upgrade
Upgrade
debian/linuxto a version that resolves this vulnerability.Fixed in 7.2.6-1 - Upgrade
Upgrade
debian/linuxto a version that resolves this vulnerability.Fixed in 7.2.12-1Fixed in 7.2.14-1 - Compensating control
In l2cap_sock.c, verify that l2cap_chan::conn.hcon corresponds to an alive hci_conn before using it, including before accessing conn->hcon->hdev.
- Compensating control
Hold l2cap_chan_lock() while performing getsockopt/setsockopt operations so the channel remains alive and l2cap_chan fields are protected from data races.
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.