CVE-2026-98809: Bluetooth: hci_sync: don't drain cmd_sync backlog on unregister

In the Linux kernel, the following vulnerability has been resolved:

Bluetooth: hcisync: don't drain cmdsync backlog on unregister

hciunregisterdev() disables cmdwork and cmdtimer, then calls hcicmdsyncclear(), whose cancelworksync() waits for hcicmdsyncwork() to return. That worker dequeues and runs every entry on cmdsyncworklist. With cmdwork disabled nothing reaches the controller, so each queued HCI command waits the full HCICMDTIMEOUT (2s).

The backlog has no bound. Userspace can keep queuing MGMT commands such as MGMTOPGETCLOCKINFO against a controller that doesn't answer. Closing /dev/vhci then blocks in vhcirelease() for backlog 2s:

INFO: task syz-executor:5749 blocked for more than 143 seconds. cancelworksync hcicmdsyncclear hciunregisterdev vhcirelease

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 HCIUNREGISTER 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 hcicmdsyncclear(). They stay on the list until the work has stopped, so hcicmdsyncdequeue() 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.