Linux Kernel CVE-2026-68085

Exploitation requires: (1) the target system must have the Linux kernel hci_uart driver loaded (CONFIG_BT_HCIUART compiled or modprobed), meaning a UART-connected Bluetooth chipset must be present and in active use - this excludes USB and PCIe Bluetooth adapters which use different drivers; (2) the attacker must be adjacent (Bluetooth proximity or local network) and have at minimum low-privileged access to the system (PR:L per CVSS vector, e.g., a local user account or a process with access to the Bluetooth subsystem); (3) a specific timing condition must exist where write_work is pending at the moment hci_uart_close() executes - this is a race window and not trivially reproducible on demand, though AC:L in the official CVSS suggests the kernel security community considers it achievable. Exploitation is limited to: systems running one of the affected kernel versions (5.10.258-5.11, 5.15.209-5.16, 6.1.175-6.2, 6.6.142-6.7, 6.12.92-6.12.96, 6.18.34-6.18.39), platforms with UART-attached Bluetooth hardware specifically (not USB BT), and requires the Bluetooth device to undergo a close/reopen cycle. Systems with USB or PCIe Bluetooth, or those with hci_uart blacklisted, are not affected.

The official CVSS 3.1 score is 8.0 (AV:A/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H), classifying this as high severity. The adjacent attack vector (AV:A) constrains reach to Bluetooth/local-network proximity, and PR:L requires some level of access to the Bluetooth interface. The AC:L rating implies the exploit is considered reliably achievable once access conditions are met, though the race condition nature (concurrent write_work cancellation and tx_skb access) would practically suggest AC:H - this discrepancy should be verified with the kernel security team. The C:H/I:H impact ratings suggest potential use-after-free exploitation beyond simple write blocking: if tx_skb is not safely zeroed before the race window closes, a heap pointer could be read or reused, enabling memory disclosure or kernel code execution on unpatched systems. EPSS at 0.17% (6th percentile) indicates very low observed exploitation probability and the vulnerability is not listed in CISA KEV, consistent with no confirmed in-the-wild exploitation. The real-world risk is higher for embedded Linux systems (IoT, SBCs) that rely on UART Bluetooth and may have longer patch cycles.

An attacker with low-privileged local access on a Linux system using a UART-attached Bluetooth device opens the hci_uart device and triggers a write operation, leaving write_work pending. The attacker then causes the device to close (e.g., via a service restart or by triggering a disconnect) at the precise moment write_work is queued, so the HCI_UART_SENDING bit is not cleared. When the device is subsequently reopened - whether by the system or another process - all future write attempts are silently blocked, causing a Bluetooth denial of service; if tx_skb is concurrently accessed before safe clearing, an additional race window may expose kernel heap data or permit a use-after-free. No public proof-of-concept exploit has been identified at time of analysis.