Answer in brief
CVE-2026-98297 records a Unknown severity vulnerability in Bluetooth: hci_core: Fix queuing tx_work after workqueue is drained. The current sources do not mark it as known exploited. The current feed maps Linux/Linux (generic), Linux/Linux (generic). Check affected ranges and fixed versions before updating.
Analysis pending evidence review
HOL Guard separates source facts from reviewed analysis. See the methodology.
A CVSS score is not reported in the current record. The current sources do not mark it as known exploited. Treat this as a source-backed prioritization signal, not a statement about your environment.
Analysis status
Analysis pending evidence review
Factual feed record only; HOL analysis is not approved for indexing. Read the methodology.
The current feed maps Linux/Linux (generic), Linux/Linux (generic). Check affected ranges and fixed versions before updating.
| Package | Affected range | Fixed version |
|---|---|---|
| Linux/Linuxgeneric | >=9cebe4680bb9a72f80c6541eb24af06db7a1fbc9 <ab0678a0701ac4de499428dc1b321659bb74d272 || >=47330cc875b36a1cf7b3543cb2cf90a7c603ce0e <e220c1242a643d97102a79f09b7ef3aa31276961 || >=525daaea459fc215f432de1b8debbd9144bf97b0 <cbb325bc150e8c0dbce004ac0e5516bcffc0de31 || >=525daaea459fc215f432de1b8debbd9144bf97b0 <6610c6fe4b8936c232048e6049bf77c70a6f759c || 60bceb9a4c693e68cc90ba4b2dfb9e000e8638ff || >=6.12.93 <6.12.112 || >=6.18.35 <6.18.54 || >=7.0.12 <7.1 | ab0678a0701ac4de499428dc1b321659bb74d272, e220c1242a643d97102a79f09b7ef3aa31276961, cbb325bc150e8c0dbce004ac0e5516bcffc0de31, 6610c6fe4b8936c232048e6049bf77c70a6f759c, 6.12.112, 6.18.54, 7.1 |
| Linux/Linuxgeneric | 7.1 | Not reported |
Published upstream
Oct 6, 2026
Evidence: source:cvelist:source_dates:source-dates:recordSource modified
Oct 6, 2026
Evidence: source:cvelist:source_dates:source-dates:recordFirst seen by HOL
Oct 6, 2026
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.
Quoted source text, attributed separately from HOL analysis.