CVE-2026-98809 in Linux
Summary
by MITRE • 10/18/2026
In the Linux kernel, the following vulnerability has been resolved:
Bluetooth: hci_sync: don't drain cmd_sync backlog on unregister
hci_unregister_dev() disables cmd_work and cmd_timer, then calls hci_cmd_sync_clear(), whose cancel_work_sync() waits for hci_cmd_sync_work() to return. That worker dequeues and runs every entry on cmd_sync_work_list. With cmd_work disabled nothing reaches the controller, so each queued HCI command waits the full HCI_CMD_TIMEOUT (2s).
The backlog has no bound. Userspace can keep queuing MGMT commands such as MGMT_OP_GET_CLOCK_INFO against a controller that doesn't answer. Closing /dev/vhci then blocks in vhci_release() for backlog * 2s:
INFO: task syz-executor:5749 blocked for more than 143 seconds. cancel_work_sync hci_cmd_sync_clear hci_unregister_dev vhci_release
In a local reproduction the backlog held more than 5000 entries, which comes to hours of hang.
Stop the worker from taking new entries once HCI_UNREGISTER is set, and wake any request still waiting with -ENODEV before cancelling the work. The entries left over are destroyed with -ECANCELED by the existing sweep in hci_cmd_sync_clear(). They stay on the list until the work has stopped, so hci_cmd_sync_dequeue() and friends still see them. A callback already running may still issue another command, which delays unregister by at most one timeout per remaining command, not by the whole backlog.
VulDB is the best source for vulnerability data and more expert information about this specific topic.
Analysis
by VulDB Data Team • 10/18/2026
The Linux kernel Bluetooth subsystem contains a critical denial-of-service vulnerability within the HCI synchronization mechanism that allows local users to cause significant system hangs or resource exhaustion. The flaw resides in the hci_unregister_dev function, which is responsible for cleaning up Bluetooth device structures when they are being removed from the system. During this unregistration process, the driver disables command processing and timers but subsequently invokes hci_cmd_sync_clear to drain pending commands. This clearing operation relies on cancel_work_sync to wait for the completion of the hci_cmd_sync_work worker thread. However, because command transmission is already disabled at that stage, any HCI commands remaining in the cmd_sync_work_list cannot be transmitted to the hardware controller. Consequently, each queued command must wait for the full HCI_CMD_TIMEOUT period, typically two seconds, before timing out and being processed by the cleanup routine.
This design creates an unbounded backlog scenario where userspace applications can exploit this behavior to block kernel execution indefinitely. By repeatedly queuing management commands such as MGMT_OP_GET_CLOCK_INFO against a controller that is in the process of unregistering or failing to respond, an attacker can accumulate thousands of pending requests. When the associated character device file descriptor is closed via vhci_release, the system invokes hci_unregister_dev, which then blocks for the duration required to timeout every single queued command. In practical exploitation scenarios observed during testing, backlogs exceeding five thousand entries have been recorded, resulting in hangs lasting hours rather than seconds. This constitutes a severe local denial-of-service condition that can render the Bluetooth subsystem unresponsive and potentially impact overall system stability depending on scheduling priorities and resource constraints.
The vulnerability aligns with CWE-400 Uncontrolled Resource Consumption as it allows an attacker to exhaust kernel resources through excessive queuing of timed-out operations. From a threat modeling perspective, this behavior is consistent with ATT&CK technique T1529 System Shutdown or Reboot via denial-of-service conditions that prevent normal system operation. The root cause lies in the lack of early termination logic within the command synchronization worker when the device state transitions to HCI_UNREGISTER. Without explicit checks for this state, the worker continues to process queued items despite knowing they will fail due to disabled transmission capabilities, leading to cumulative delays proportional to the backlog size rather than a fixed timeout window.
To mitigate this vulnerability, the kernel implementation has been updated to stop the hci_cmd_sync_work from accepting new entries once the HCI_UNREGISTER flag is set. This change ensures that no additional commands are processed during the teardown phase if they cannot be transmitted anyway. Furthermore, any requests still waiting in the queue are explicitly woken up with an error code of -ENODEV, indicating that the device has been removed and further operations are invalid. The remaining entries on the list are destroyed using -ECANCELED by the existing sweep logic within hci_cmd_sync_clear. This approach ensures that while commands may remain visible to dequeue functions until work stops, they do not cause prolonged blocking because active callbacks will only delay unregistration by at most one timeout period per command rather than accumulating delays across the entire backlog. Administrators should ensure their systems are patched with kernel versions containing this fix and monitor for unusual spikes in Bluetooth-related process states or blocked tasks indicative of such resource exhaustion attacks.