CVE-2026-90256: Bluetooth: L2CAP: use proto_lock for l2cap_data to fix l2cap_disconn_ind
In the Linux kernel, the following vulnerability has been resolved:
Bluetooth: L2CAP: use protolock for l2capdata to fix l2capdisconnind
hciconn::l2capdata is accessed without locks in l2capdisconnind via hciconntimeout (discwork) -> hciprotodisconnind -> l2capdisconnind. This is UAF if the l2capconn is deleted concurrently.
discwork is disabled sync in hciconndel(), so we cannot take hcidevlock in discwork.
Fix by using protolock to guard l2capdata, in addition to hdev->lock which is held in other access paths.
Affected Software
Event History
Frequently Asked Questions
What condition is required for this issue to occur?
The issue requires l2cap_disconn_ind to access hci_conn::l2cap_data while the associated l2cap_conn is being deleted concurrently. This race can result in a use-after-free.
Which code path is involved in the vulnerable access?
The access occurs through hci_conn_timeout (disc_work), then hci_proto_disconn_ind, then l2cap_disconn_ind. The vulnerable path cannot take hci_dev_lock because disc_work is synchronously disabled during hci_conn_del().
What synchronization change resolves the race?
The resolved change uses proto_lock to guard hci_conn::l2cap_data. This supplements hdev->lock, which protects the data in other access paths.