CVE-2026-98809: Bluetooth: hci_sync: don't drain cmd_sync backlog on unregister
Bluetooth: hcisync: don't drain cmdsync backlog on unregister
Affected Software
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Upgrade
Upgrade
debian/linuxto a version that resolves this vulnerability.Fixed in 6.12.113-1 - Upgrade
Upgrade
debian/linuxto a version that resolves this vulnerability.Fixed in 7.2.10-1 - Upgrade
Upgrade
debian/linux-6.12to a version that resolves this vulnerability.Fixed in 6.12.113-1~deb12u1 - Upgrade
Upgrade
debian/linuxto a version that resolves this vulnerability.Fixed in 6.12.115-2Fixed in 7.2.12-1Fixed in 7.2.15-1 - Upgrade
Upgrade
linux/Kernelto a version that resolves this vulnerability.Fixed in 6.1.191 - Upgrade
Upgrade
linux/Kernelto a version that resolves this vulnerability.Fixed in 6.6.160 - Upgrade
Upgrade
linux/Kernelto a version that resolves this vulnerability.Fixed in 6.12.113 - Upgrade
Upgrade
linux/Kernelto a version that resolves this vulnerability.Fixed in 6.18.56 - Upgrade
Upgrade
linux/Kernelto a version that resolves this vulnerability.Fixed in 7.2.10 - Upgrade
Upgrade
azurelinux/kernelto a version that resolves this vulnerability.Fixed in 6.6.161.1-1 - Compensating control
In Bluetooth hci_sync, once HCI_UNREGISTER is set, prevent hci_cmd_sync_work() from dequeuing new entries and wake requests still waiting with -ENODEV before cancelling the work, so hci_cmd_sync_clear() does not drain the cmd_sync backlog.
Event History
Frequently Asked Questions
Who is realistically exposed to this issue?
Systems using the Linux kernel Bluetooth stack are exposed when a controller can be made unresponsive while userspace queues Bluetooth MGMT commands. The described reproduction uses /dev/vhci, where closing the virtual HCI device can block during unregister.
What does an attacker or local user need to do to trigger the hang?
They need to queue an unbounded backlog of MGMT commands, such as MGMT_OP_GET_CLOCK_INFO, against a controller that does not answer, then cause the controller to be unregistered. Each queued command can wait for the full two-second HCI command timeout while unregister is in progress.
How can I recognize that a system is affected?
A process closing /dev/vhci may remain blocked in vhci_release() for a long time. Kernel task-blocked reports can show a stack involving cancel_work_sync, hci_cmd_sync_clear, hci_unregister_dev, and vhci_release.
What changes after the fix?
Once unregister begins, the command-sync worker stops taking new queued entries and waiting requests are awakened with -ENODEV. Remaining queued entries are later destroyed with -ECANCELED rather than being run one by one through the command timeout.