CVE-2026-98809

None

CVSS

—

EPSS

0.2%

Published

Oct 18, 2026

CISA due date

—

Cloudanix analysis

Schedule a fix SSVC: Track

A problem in how Linux handles Bluetooth connections can freeze the whole computer for a very long time when certain Bluetooth devices are disconnected.

Exploitation: Local Privilege
Attacker needs: Local User
Complexity: Low
Impact: Denial Of Service
Component: OS kernel
Class: Denial of service
Remediation: Upgrade
Effort: Medium
Patch risk: Low

What it actually does

The flaw permits an unbounded backlog of HCI command sync entries to accumulate during hci_unregister_dev because cmd_work is disabled while the worker still drains the list, each entry blocking for the full HCI_CMD_TIMEOUT (2s) with no bound on queue length from userspace MGMT commands.

Why it matters to the business

Local operations that unregister Bluetooth devices (driver unload, virtual controller close) can cause multi-hour system hangs, degrading availability on any Linux host exposing Bluetooth interfaces to untrusted processes.

How an attack unfolds

An attacker with local access repeatedly issues MGMT_OP_GET_CLOCK_INFO or similar commands against a controller that does not respond, then closes /dev/vhci or otherwise triggers unregister; the resulting backlog forces hci_cmd_sync_clear to wait sequentially on each 2-second timeout.

How to fix it

Update the Linux kernel to a version containing the fix that sets HCI_UNREGISTER to stop accepting new entries, wakes pending requests with -ENODEV, and allows the existing sweep to cancel leftovers with -ECANCELED.

How to confirm the fix worked

Confirm the kernel tree includes the hci_sync changes that check HCI_UNREGISTER before enqueuing and that reproduce unregister operations complete without multi-second blocking; inspect dmesg for absence of the reported INFO: task blocked messages.

Typical attack path

Issue repeated MGMT commands against a non-responsive Bluetooth controller
Trigger device unregister (vhci_release, hci_unregister_dev)
Block in cancel_work_sync for backlog * 2 seconds

How to detect it

Search kernel logs and traces for extended blocking in cancel_work_sync, hci_cmd_sync_clear, or vhci_release; correlate with high volumes of MGMT command queuing immediately preceding unregister events.

What your security team should do

Prioritize kernel updates that resolve the Bluetooth hci_sync backlog issue
Restrict unprivileged access to /dev/vhci and MGMT sockets where feasible
Monitor kernel changelogs for Bluetooth HCI patches and test in lab environments before broad rollout

The record

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.

Affected packages

Ecosystem	Package	Introduced	Fixed