CVE-2026-68393

CVE-2026-68393 is a use-after-free in the Linux kernel's Bluetooth hci_sync layer, but calling it a 'missing lock' undersells what's actually happening. The vulnerability is a structurally flawed RCU usage pattern: the code performs an hci_conn_hash lookup under RCU protection, then dereferences the returned pointer after exiting the RCU critical section. Once the grace period ends, the freed connection object becomes accessible through that stale pointer—a textbook time-of-check-time-of-use adapted to kernel concurrency. What makes this analytically significant is the patch's framing. The fix extends existing critical sections rather than creating new ones, and the commit explicitly states this work is 'in preparation for RCU lockdep requirement.' This signals systematic hardening of the hci_sync layer, not an isolated fix. The Bluetooth maintainers are retroactively annotating code paths that were accidentally safe under coarse-grained locking but become vulnerable under fine-grained RCU. The patch also addresses a separate accept_list locking violation—accessing hdev->accept_list without holding hdev->lock. This concurrent failure mode doesn't require winning the RCU race; an attacker can corrupt accept_list through the locking violation alone. The presence of two distinct synchronization failures in one commit indicates pervasive synchronization problems, not isolated mistakes. The EPSS score of 0.00242 reflects narrow triggerability, not narrow impact. The conn pointer is the central reference object for active Bluetooth connections—when corrupted, it poisons every downstream operation that trusts it: connection teardown, SCO audio routing, pairing state machines, LE parameter updates. Exploitation requires precise timing of concurrent connection events, but the blast radius, once triggered, is systemic. The 'preparation for RCU lockdep' language suggests this is a proactive enforcement action—lockdep annotations becoming mandatory will surface additional RCU misuse instances as discrete CVEs. If this pattern exists in actively-refactored hci_sync code, it likely exists in forgotten corners: deprecated features like accept_list, vendor extensions, and debug paths that haven't been touched in years. Other _sync-migrated subsystems (NFC, WireGuard) with similar refactoring histories may carry equivalent debt.

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