CVE-2026-98297: Bluetooth: hci_core: Fix queuing tx_work after workqueue is drained
In the Linux kernel, the following vulnerability has been resolved:
Bluetooth: hcicore: Fix queuing txwork after workqueue is drained
hcisendacl(), hcisendsco() and hcisendiso() queue hdev->txwork unconditionally. They can run from the L2CAP/SCO/ISO socket send path while hcidevclosesync() is draining hdev->workqueue (HCIDEVDOWN racing with a socket write). Since that queuework() is not chained work from the txwork worker itself, queuework() sees the queue marked WQDRAINING, warns "cannot queue %ps on wq %s", and drops the work:
WARNING: CPU: 1 PID: 5985 at kernel/workqueue.c:2352 queuework Call Trace: queueworkon l2capchansend l2capsocksendmsg ...
hcidevclosesync() already sets HCICMDDRAINWORKQUEUE before draining, but only hcicmdwork() and handlecmdcntandtimer() check it before queuing. Route the txwork producers through the same guard via a shared hcischedtx() helper.
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.8-1 - Upgrade
Upgrade
debian/linux-6.12to a version that resolves this vulnerability.Fixed in 6.12.113-1~deb12u1 - Upgrade
Upgrade
linux/Kernelto a version that resolves this vulnerability.Fixed in 6.12.112 - Upgrade
Upgrade
linux/Kernelto a version that resolves this vulnerability.Fixed in 6.18.54 - Upgrade
Upgrade
linux/Kernelto a version that resolves this vulnerability.Fixed in 7.2.8 - Upgrade
Upgrade
debian/linuxto a version that resolves this vulnerability.Fixed in 6.1.176-1Fixed in 6.1.190-1Fixed in 6.12.115-2Fixed in 7.2.12-1Fixed in 7.2.15-1 - Upgrade
Upgrade
ubuntu/linux-hwe-7.0to a version that resolves this vulnerability.Fixed in 7.0.0-42.42~24.04.1 - Upgrade
Upgrade
ubuntu/linux-riscv-7.0to a version that resolves this vulnerability.Fixed in 7.0.0-42.42.1~24.04.1 - Upgrade
Upgrade
ubuntu/linuxto a version that resolves this vulnerability.Fixed in 7.0.0-42.42 - Upgrade
Upgrade
ubuntu/linux-awsto a version that resolves this vulnerability.Fixed in 7.0.0-1016.17 - Upgrade
Upgrade
ubuntu/linux-gcpto a version that resolves this vulnerability.Fixed in 7.0.0-1016.18 - Upgrade
Upgrade
ubuntu/linux-ibmto a version that resolves this vulnerability.Fixed in 7.0.0-1017.17 - Upgrade
Upgrade
ubuntu/linux-oem-7.0to a version that resolves this vulnerability.Fixed in 7.0.0-1017.17 - Upgrade
Upgrade
ubuntu/linux-oracleto a version that resolves this vulnerability.Fixed in 7.0.0-1015.16 - Upgrade
Upgrade
ubuntu/linux-riscvto a version that resolves this vulnerability.Fixed in 7.0.0-42.42.1
Event History
Frequently Asked Questions
When does the issue occur?
It occurs when an L2CAP, SCO, or ISO socket send path queues Bluetooth transmit work while hci_dev_close_sync() is draining the device workqueue during an HCIDEVDOWN event. This is a race between a socket write and Bluetooth device shutdown.
How can I tell whether a system is encountering this issue?
The kernel can emit a workqueue warning stating that it cannot queue work on a draining workqueue, with a message like "cannot queue %ps on wq %s". The call trace may include queue_work_on, l2cap_chan_send, l2cap_sock_sendmsg, and hci_dev_close_sync().
What can be done before applying the fix?
Avoid allowing L2CAP, SCO, or ISO socket writes to race with Bluetooth device shutdown or HCIDEVDOWN operations. The resolved change routes transmit-work scheduling through a guard that prevents queuing while the workqueue is being drained.