CVE-2026-74533

This CVE exposes a race condition in the Linux kernel's Bluetooth ISO subsystem where the hci_conn::iso_data pointer is accessed and modified without lock or RCU protection. The vulnerability creates races between iso_recv (reading the pointer) and iso_conn_free (freeing it), and similarly between iso_conn_add and iso_conn_free. The fix introduces a spinlock named proto_lock specifically to protect the iso_data field — a dedicated lock rather than reuse of any existing synchronization primitive in hci_conn. What makes this值得注意 is the topology of the race: iso_recv runs on a bounded workqueue (hdev->workqueue), while iso_conn_free can fire from arbitrary task context including interrupt handlers or user-triggered ioctls. This asymmetry means the attack surface is asymmetric — one side of the race is far more controllable by an attacker than the other, which explains the CVSS 8.8 score despite the fix being conceptually simple. The addition of a new spinlock rather than reuse of an existing one raises a structural question: was hci_conn's concurrency model designed before the ISO path existed, and the ISO work was bolted on without updating the parent's locking assumptions? This would be classic refactoring debt — new code path, existing struct, no audit of whether synchronization assumptions still held. The same unprotected-pointer topology has generated CVEs in USB driver-core, netfilter, and the timer subsystem over the past several years. Each time the pattern recurs: workqueue-bound reader, arbitrary-context deleter, no lock, refcounted object. The kernel's own concurrency guidance never codified a clear decision tree for this topology — RCU is the wrong tool when you need to block while manipulating reference counts, but a spinlock wasn't applied as a matter of course. Developers solved the same puzzle from scratch rather than inheriting a solution. The proto_lock fix is correct for iso_data, but it's field-specific. Other fields in hci_conn may have identical exposure — the question is whether the Bluetooth maintainers treat this as a one-field patch or a trigger to audit the rest of hci_conn for similar unprotected races. The workqueue-as-bounding-assumption that iso_recv runs on was never a formal contract about who can call iso_conn_free. That contract mismatch is the deeper gap this CVE exposes: implicit execution-context assumptions clashing with explicit concurrency primitives.

Reviewed through automated stages and approved by a human before publication.