Linux Kernel EUVD-2026-27647

Local authenticated user privileges (PR:L in CVSS) are required to trigger Bluetooth operations. The system must have the Bluetooth subsystem (hci_sock or similar) exposed to user-space and the kernel must be compiled with Bluetooth (CONFIG_BT) enabled. Exploitation requires precise timing to collide concurrent access to hdev->req_status across multiple workqueues, which is more likely on high-CPU-count systems and under heavy Bluetooth workload. Default kernel builds with Bluetooth enabled are vulnerable; systems with Bluetooth compiled out are unaffected. Non-root users with capability to open AF_BLUETOOTH sockets and submit HCI commands can trigger the vulnerability.

This vulnerability presents moderate real-world risk with specific limiting factors. The CVSS score of 5.5 (AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H) correctly reflects local attack vector requiring authenticated user privileges, but the impact is strictly availability (denial of service through system hang or memory corruption), not confidentiality or integrity. The extremely low EPSS score (0.02%, percentile 5%) suggests exploitation is difficult despite the high CVSS score - this discrepancy is explained by the requirement for precise timing of concurrent Bluetooth operations across multiple CPUs to trigger the race condition. The vulnerability is not in the CISA KEV catalog at time of analysis, and no public proof-of-concept has emerged, indicating this is a theoretical data-race identified through kernel auditing rather than observed exploitation. Real-world impact depends on system workload (high CPU contention increases collision probability) and Bluetooth subsystem activity. For most server/desktop systems with moderate Bluetooth usage, triggering this race consistently would require local access and deliberate multi-threaded attack code. The patch availability and upstream kernel version tracking through stable branches (6.12.83, 6.18.24, 6.19.14, 7.0) indicate this is a mainline kernel issue that distributions will address through routine updates.

A local authenticated user with system access writes a multi-threaded C program that rapidly initiates and cancels Bluetooth HCI commands while simultaneously triggering connection abort operations. The program exploits the race condition by creating precise timing windows where hci_cmd_sync_complete() and __hci_cmd_sync_sk() access hdev->req_status concurrently without locks, causing the kernel's wait_event condition to behave incorrectly due to compiler-level store reordering. This results in the HCI command handler missing state transitions and entering a deadlock or exception state, causing the kernel to hang or panic the Bluetooth subsystem.