Linux Kernel EUVD-2026-81953

Requires: (1) a kernel built with CONFIG_BT and the Bluetooth L2CAP stack active; (2) a local process that creates and then releases an L2CAP listening socket; (3) an attacker within Bluetooth radio range (AV:A) able to initiate an inbound L2CAP connection to the target PSM; and (4) winning a narrow timing race between l2cap_sock_release()/teardown setting the parent state to BT_CLOSED and l2cap_new_connection adding the new socket to the accept queue. Limiting factors: Bluetooth proximity gating (not remotely reachable over IP), the probabilistic race window (chan->state read without consistent locking), the need for a local process to be actively managing an L2CAP listener, and the niche nature of the L2CAP-listen code path. This is NOT default-configuration remote exploitation.

This is a legitimate memory-safety flaw (a use-after-free on a dangling parent socket reference) but the risk signals are moderate, not urgent. No EPSS score, no CISA KEV listing, and no public PoC are present in the input, so exploitation status is: no public exploit identified at time of analysis. The vendor CVSS of 8.0 (AV:A/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H) overstates ease of exploitation on one axis: the entire vulnerability is a documented race window ('l2cap_sock_new_connection_cb() may race with parent l2cap_chan teardown, due to chan->state accessed without consistent locking'), which realistically warrants AC:H rather than AC:L - the attacker/local task must win a narrow timing race between l2cap_sock_release() teardown and an incoming l2cap_connect. AV:A is correct because the triggering new connection arrives over the Bluetooth radio, meaning the attacker must be within Bluetooth range (proximity-gated, not internet-facing). Unlike its NULL-deref sibling CVE-2026-90091, this is a true UAF, so the C:H/I:H/A:H impact set is defensible (memory corruption can escalate beyond a crash), though weaponizing a kernel UAF into reliable code execution is non-trivial. The CWE is missing from the record - this is CWE-416 (UAF) layered on CWE-362 (race). Net: a real kernel bug worth patching in the normal cycle, but the Bluetooth-adjacency requirement, race-window timing, local privilege prerequisite, and niche CONFIG_BT + L2CAP-listen path make it far from a mass-exploitation priority.

A local process on a Bluetooth-enabled Linux host holds an L2CAP listening socket and then closes/releases it while an attacker within Bluetooth range initiates an inbound L2CAP connection to the same PSM. If the incoming connection callback wins the race against parent-socket teardown, the new socket is queued on the now-closed (BT_CLOSED) parent's accept queue, leaving a dangling parent reference that is dereferenced as a use-after-free - corrupting kernel memory. No public exploit code is identified at time of analysis.