CVE-2026-98297

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.