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.
Fix
Nothing published yet: no patch, vendor advisory or mitigation reference on NVD, no vendor advisory in the News for this CVE, not in CISA's KEV, no fixed package version. BaselineWatch does not guess at one.
Change history 5
- StatusReceived → PublishedNVD modified 2026-10-21 12:54
- References+1 references (now 5)NVD modified 2026-10-21 13:21
- StatusPublished → ReceivedNVD modified 2026-10-21 13:21
- StatusReceived → PublishedNVD modified 2026-10-19 09:17
- First seenunscoredNVD modified 2026-10-19 10:18
Affected (CPE criteria) 0
NVD has not attached CPE configurations yet.
References 5
- https://git.kernel.org/stable/c/6610c6fe4b8936c232048e6049bf77c70a6f759c
- https://git.kernel.org/stable/c/8010212197d4a3ee714f78ed77048d0b712ff925
- https://git.kernel.org/stable/c/ab0678a0701ac4de499428dc1b321659bb74d272
- https://git.kernel.org/stable/c/cbb325bc150e8c0dbce004ac0e5516bcffc0de31
- https://git.kernel.org/stable/c/e220c1242a643d97102a79f09b7ef3aa31276961