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

Severity: unknown
Exploited in the wild: not listed in CISA KEV
EPSS: 0.2% probability of exploitation in the next 30 days
Public exploit or detection template: none known
Published: 2026-10-06 · updated 2026-10-30

Description

In the Linux kernel, the following vulnerability has been resolved: Bluetooth: hci_core: Fix queuing tx_work after workqueue is drained hci_send_acl(), hci_send_sco() and hci_send_iso() queue hdev->tx_work unconditionally. They can run from the L2CAP/SCO/ISO socket send path while hci_dev_close_sync() is draining hdev->workqueue (HCIDEVDOWN racing with a socket write). Since that queue_work() is not chained work from the tx_work worker itself, __queue_work() sees the queue marked __WQ_DRAINING, warns "cannot queue %ps on wq %s", and drops the work: WARNING: CPU: 1 PID: 5985 at kernel/workqueue.c:2352 __queue_work Call Trace: queue_work_on l2cap_chan_send l2cap_sock_sendmsg ... hci_dev_close_sync() already sets HCI_CMD_DRAIN_WORKQUEUE before draining, but only hci_cmd_work() and handle_cmd_cnt_and_timer() check it before queuing. Route the tx_work producers through the same guard via a shared hci_sched_tx() helper.

Affected products

Linux: from 6.12.93 before 6.12.112; from 6.18.35 before 6.18.54; from 7.0.12 before 7.1 — fixed in 6.12.112, 6.18.54, 7.1

How to fix

Upgrade to a fixed version: Linux 6.12.112, 6.18.54, 7.1. Check the vendor advisory for mitigations.

References

Get alerted when CVE-2026-98297 or the next vulnerability affects your stack