CVE-2026-68085: Linux Kernel Privilege Escalation Flaw

CVE-2026-68085 Overview

CVE-2026-68085 is a race condition vulnerability in the Linux kernel's Bluetooth hci_uart driver. The flaw stems from improper handling of the HCI_UART_SENDING bit in tx_state, which is not cleared when write_work is canceled in hci_uart_close(). When the device is reopened later, this stale bit blocks future writes if write_work was pending at close time. The vulnerability affects the Bluetooth subsystem of the Linux kernel and is exploitable from an adjacent network position over the Bluetooth interface. The upstream fix clears HCI_UART_SENDING when canceling the work and adopts disable_work_sync combined with enable_work to make tx_skb clearing safe.

Critical Impact
Adjacent-network attackers can trigger a denial-of-service or state corruption condition in the Bluetooth UART driver, blocking future writes and potentially impacting confidentiality, integrity, and availability of affected systems.

Affected Products

Linux kernel Bluetooth subsystem (drivers/bluetooth/hci_ldisc.c and related hci_uart code paths)
Distributions shipping vulnerable stable branches prior to the referenced upstream commits
Embedded and mobile devices using Bluetooth over UART transport

Discovery Timeline

2026-08-10 - CVE-2026-68085 published to NVD
2026-08-13 - Last updated in NVD database

Technical Details for CVE-2026-68085

Vulnerability Analysis

The vulnerability resides in the Linux kernel's Bluetooth HCI UART transport layer. The HCI_UART_SENDING bit in tx_state serves as a lock indicating that write_work is pending, preventing concurrent queueing. When hci_uart_close() cancels the pending write_work, the code fails to clear this bit. On subsequent device reopen, the stale HCI_UART_SENDING bit causes hci_uart_tx_wakeup() to skip queueing, silently dropping outbound HCI frames.

The issue is compounded by unsafe clearing of tx_skb, which the original code handled with cancel_work_sync alone. This leaves a race window where the work could be requeued between cancellation and skb cleanup. The fix moves cancellation into hci_uart_flush(), which already purges the proto tx queue, and uses disable_work_sync followed by enable_work to guarantee safe state transitions.

Root Cause

The root cause is a state-management defect in the hci_uart close path. HCI_UART_SENDING is set when work is queued but never cleared when the work is canceled during shutdown. This is a race condition [CWE-362 category] combined with improper resource cleanup in the driver lifecycle.

Attack Vector

Exploitation requires adjacent network access over Bluetooth and low privileges on the target. An attacker able to influence Bluetooth session lifecycle events, including forced disconnects during active transmission, can drive the driver into the stuck state. Recovery typically requires a module reload or system reboot, resulting in denial of service for Bluetooth-dependent functionality.

No verified public exploit code is available. See the upstream fix commits referenced in the Kernel Git Commit Review 1b0d946 and Kernel Git Commit Review d52446b for the code-level details.

Detection Methods for CVE-2026-68085

Indicators of Compromise

Bluetooth interface stops transmitting HCI frames after a close/reopen cycle without kernel error messages
dmesg entries related to hci_uart transport that show queued but never dispatched work
Persistent Bluetooth connectivity failures on affected devices that resolve only after module reload or reboot

Detection Strategies

Monitor kernel version inventory across endpoints and flag hosts running kernel branches prior to the patched commits
Correlate Bluetooth service failures with recent hci_uart_close() invocations in kernel logs
Track abnormal Bluetooth reconnection loops from adjacent devices that could indicate probing for the race window

Monitoring Recommendations

Ingest kernel and syslog telemetry into a centralized data lake for retrospective analysis of Bluetooth subsystem state
Alert on repeated hci_uart open/close cycles from the same peer within short time windows
Track patch compliance for Linux kernel packages across fleet endpoints and Bluetooth-enabled IoT assets

How to Mitigate CVE-2026-68085

Immediate Actions Required

Apply the upstream Linux kernel patches referenced in the vendor commits to all affected systems
Prioritize patching on mobile, embedded, and IoT devices that rely on Bluetooth UART transport
Disable the Bluetooth stack on systems where the feature is not required until patches are deployed

Patch Information

The fix is committed to the mainline Linux kernel across multiple stable branches. Reference commits: Kernel Git Commit 1b0d946, Kernel Git Commit 714d861, Kernel Git Commit b9dd39c, and Kernel Git Commit d52446b. Verify the fix by checking that hci_uart_flush() clears HCI_UART_SENDING and uses disable_work_sync plus enable_work around tx_skb cleanup.

Workarounds

Unload the hci_uart kernel module on systems that do not require Bluetooth: modprobe -r hci_uart
Restrict Bluetooth pairing and disable discoverability to reduce adjacent-network attack surface
Use MAC filtering and short pairing windows to limit exposure until patches are applied

bash

# Disable Bluetooth service where not required
sudo systemctl disable --now bluetooth.service

# Blacklist the hci_uart module
echo "blacklist hci_uart" | sudo tee /etc/modprobe.d/blacklist-hci_uart.conf
sudo update-initramfs -u

# Verify installed kernel version against patched builds
uname -r