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
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Configuration
Guard hci_conn::l2cap_data with proto_lock in l2cap_disconn_ind and other access paths, in addition to hdev->lock, to prevent concurrent deletion of l2cap_conn.
Linux kernel Bluetooth L2CAP l2cap_data locking = proto_lock in addition to hdev->lock
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.