CVE-2026-98297: Bluetooth: hci_core: Fix queuing tx_work after workqueue is drained

Published Oct 6, 2026

Updated

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

1 affected component

Linux Linux kernel

Remediation

Recommended actions to resolve this vulnerability, in priority order.

Compensating control
Route hci_send_acl(), hci_send_sco(), and hci_send_iso() tx_work producers through a shared hci_sched_tx() helper that checks HCI_CMD_DRAIN_WORKQUEUE before queueing work.

Event History

Oct 6, 2026

CVE Published

via MITRE·08:45 AM

Data Sourced

via MITRE·08:45 AM

Description

Data Sourced

via NVD·09:18 AM

Description

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.

CVE-2026-98297: Bluetooth: hci_core: Fix queuing tx_work after workqueue is drained

Affected Software

Remediation

Event History

Frequently Asked Questions

When does the issue occur?

How can I tell whether a system is encountering this issue?

What can be done before applying the fix?

Company

Resources

Contact

Frequently Asked Questions

When does the issue occur?

How can I tell whether a system is encountering this issue?

What can be done before applying the fix?