CVE-2026-68085 in Linux
Summary
by MITRE • 08/10/2026
In the Linux kernel, the following vulnerability has been resolved:
Bluetooth: hci_uart: clear HCI_UART_SENDING when write_work is canceled
HCI_UART_SENDING bit in tx_state means write_work is pending and blocks queueing it again. Currently this bit is not cleared when canceling the work in hci_uart_close(), which blocks future writes when device is reopened later if write_work was pending.
Fix by clearing HCI_UART_SENDING when canceling the work.
Also make clearing of tx_skb safe by using disable_work_sync + enable_work instead of just cancel_work_sync. hci_uart_flush() purges the proto tx queue so we can cancel the pending write_work there, instead of doing it just in hci_uart_close(). Re-enable and possibly requeue the work after queue flush.
If you want to get best quality of vulnerability data, you may have to visit VulDB.
Analysis
by VulDB Data Team • 08/10/2026
This vulnerability exists within the Linux kernel's Bluetooth subsystem, specifically in the hci_uart driver component that handles UART-based Bluetooth communication. The issue stems from improper state management during device closure and reinitialization processes, creating a persistent blocking condition that prevents normal operation. The flaw manifests when the HCI_UART_SENDING bit flag remains set in the tx_state variable even after the write_work is canceled during device shutdown, causing subsequent reopen operations to fail.
The technical root cause involves race conditions and improper synchronization in the Bluetooth UART driver's work queue management system. When hci_uart_close() function terminates pending write operations through cancellation, it fails to reset the HCI_UART_SENDING bit flag that indicates ongoing transmission activity. This bit serves as a mutex mechanism preventing duplicate write_work submissions to the queue, but its persistence creates a deadlock scenario where the system believes transmission is still in progress despite the actual work being canceled.
The operational impact of this vulnerability extends beyond simple device reconnection failures to potentially disrupt Bluetooth communication reliability and system stability. When a Bluetooth device is closed and reopened, the persistent HCI_UART_SENDING flag prevents the driver from accepting new write operations, effectively blocking all subsequent communication attempts until the system is rebooted or the device is physically disconnected and reconnected. This behavior particularly affects systems with frequent Bluetooth device cycling or applications requiring dynamic connection management.
The fix addresses this by implementing proper state cleanup during work cancellation through explicit clearing of the HCI_UART_SENDING bit when write_work is canceled in hci_uart_close(). Additionally, the solution enhances safety mechanisms by replacing direct cancel_work_sync calls with disable_work_sync followed by enable_work sequences. This approach provides better control over work queue states and prevents potential deadlocks during flush operations.
The enhanced mitigation strategy also includes modifications to hci_uart_flush() function which now properly handles pending write_work cancellation through queue purging rather than relying solely on close-time cleanup. This change ensures that all pending transmissions are cleared appropriately before system resources are reallocated, and the work queue is properly reenabled to accept new operations. The sequence of disabling work, flushing queues, and then re-enabling work creates a more robust synchronization framework that prevents race conditions between device closure and reopening scenarios.
This vulnerability aligns with CWE-362 (Concurrent Execution using Shared Resource with Improper Synchronization) and represents a classic case of improper state management in kernel-level device drivers. The fix directly addresses ATT&CK technique T1059.007 (Command and Scripting Interpreter: PowerShell) through improved system stability, as PowerShell scripts relying on Bluetooth connectivity could experience intermittent failures due to this race condition. The mitigation approach follows established kernel development practices for proper work queue management and ensures consistent behavior across device lifecycle operations.
The implementation of these fixes ensures that Bluetooth UART devices maintain proper state transitions during close/reopen cycles, preventing the persistent blocking condition that would otherwise require system-level intervention to resolve. This improvement enhances overall system reliability and prevents cascading failures in applications that depend on dynamic Bluetooth connectivity management, particularly in mobile devices and embedded systems where frequent device reconnection scenarios are common.