KernelScan.io

HIGH

l2cap DisconnInd UAF

CVE-2026-90256

CVSS 8.8 / 10.0 NVD

CVSS:3.1/AV:A/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H

KernelScan AI7.1HIGH

01

In the Linux kernel, the following vulnerability has been resolved: Bluetooth: L2CAP: use proto_lock for l2cap_data to fix l2cap_disconn_ind hci_conn::l2cap_data is accessed without locks in l2cap_disconn_ind via hci_conn_timeout (disc_work) -> hci_proto_disconn_ind -> l2cap_disconn_ind. This is UAF if the l2cap_conn is deleted concurrently. disc_work is disabled sync in hci_conn_del(), so we cannot take hci_dev_lock in disc_work. Fix by using proto_lock to guard l2cap_data, in addition to hdev->lock which is held in other access paths.

02

Engine v0.6.0

Risk summary

A use-after-free vulnerability exists in the Bluetooth L2CAP disconnect indication handler, where a connection object can be freed by a concurrent teardown thread while still being accessed. Any local user with Bluetooth socket access can trigger the race, and a nearby Bluetooth device may also trigger it via connection timeout. Exploitation could lead to kernel memory corruption, information disclosure, or denial of service.

Affectednet/bluetooth/l2cap_core.c (Bluetooth L2CAP)

Vulnerability analysis

A Bluetooth connection object can be freed while a disconnect timeout path is still reading it, because the timeout path accessed the connection pointer without synchronization. The timeout path could not safely use the same lock that protects teardown, so the fix adds separate synchronization around the shared pointer so the timeout path either sees a live connection or none at all, never one that has already been freed. Any local user who can open Bluetooth sockets to set up and tear down connections can trigger the race, and a nearby Bluetooth device can also fire the timeout; the system must have Bluetooth enabled.

03

BranchIntroducedFixed inPatch commit
6.66.6.846.7b495a3a9b33b
6.126.12.206.132b66c83ff175
6.136.13.86.14—
7.2—7.2.6—
mainline—7.3-rc1—