Linux Kernel CVE-2026-90256

Requires the target to have the Bluetooth subsystem active and reachable (AV:A, Bluetooth proximity) with an L2CAP connection being established/torn down. Exploitation depends on winning a concurrency race between the hci_conn_timeout disconnect-work handler (disc_work) invoking l2cap_disconn_ind and a concurrent deletion of the l2cap_conn - the l2cap_data pointer is read unlocked during this window. Limiting factors: the attacker must be within Bluetooth range, the bug is a timing-dependent race (not deterministically triggerable), and it only manifests on kernels in the affected 6.6.84-6.14 ranges lacking the proto_lock fix. Servers and headless systems without Bluetooth hardware/stack are not exposed.

The vendor CVSS of 8.8 (AV:A/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H) significantly overstates real-world risk for this bug. The root cause is a race condition: hci_conn::l2cap_data is read without locking in l2cap_disconn_ind, reached via the hci_conn_timeout (disc_work) teardown path, and a concurrent deletion of the l2cap_conn frees the object mid-access - a classic use-after-free (CWE-416) predicated on a race window (CWE-362). Two signals conflict with the vendor score. First, AC:L is wrong for a race that requires winning a narrow timing window between disc_work firing and concurrent l2cap_conn teardown - this is realistically AC:H. Second, C:H/I:H are optimistic: this is a crash-primary UAF with no described path to controlled read/write or code execution, so confidentiality/integrity impact is not substantiated and the realistic impact is availability (kernel oops/panic). EPSS, KEV, and POC data are all absent from the input - there is no evidence of active exploitation or public exploit code. Net: this is a genuine but hard-to-trigger local/proximity denial-of-service bug, not a high-priority network-exploitable RCE; my independent assessment is roughly 4.8 rather than 8.8.

An attacker within Bluetooth range establishes and then rapidly tears down L2CAP connections to a target device, racing the hci_conn_timeout disconnect-work handler against concurrent l2cap_conn deletion so that l2cap_disconn_ind dereferences already-freed l2cap_data. Winning the race corrupts kernel memory and crashes the host (kernel panic/oops), producing a denial of service. No public exploit code is identified at time of analysis, and success depends on hitting a narrow timing window.