Skip to main content
VulnerabilityPublished Updated

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

Affects Linux kernelSource CVE Database V5

0

Not known to be exploited · fixed in e220c1242a643d97102a79f09b7ef3aa31276961 : update Linux kernel when convenient.

Data as of 26 Oct 2026, 13:07 UTC

Severity
Unrated

Rated by Threat Radar · CVSS not yet scored by NVD

EPSS
0.1% chance of exploitation in 30 days – higher than 6% of CVEsExploit Prediction Scoring System: the likelihood attackers will use this flaw soon.
Patch
Available – fixed in e220c1242a643d97102a79f09b7ef3aa31276961, cbb325bc150e8c0dbce004ac0e5516bcffc0de31, ab0678a0701ac4de499428dc1b321659bb74d272 +5

Exploitation evidence

  1. Disclosed: evidence found.

    CVE published 6 Oct 2026

  2. Detectable: no evidence on record.

    No public nuclei template indexed

  3. Weaponised: no evidence on record.

    No public exploit code indexed in Metasploit or Exploit-DB

  4. Exploited in the wild: no evidence on record.

    Not in CISA KEV and no source reports exploitation

  5. Observed by OffSeq Mirage: no evidence on record.

    No attack traffic recorded by OffSeq Mirage sensors

A missing step is not evidence of safety. Sources: cve.org (opens in a new tab), the Metasploit, Exploit-DB and nuclei-templates index as of 26 Oct 2026.

What to do

Upgrade to a fixed release listed under Affected software.

Affected software

ProductAffectedFixed in
LinuxLinuxAffected
  • >=6.12.93 <6.12.112
  • >=6.18.35 <6.18.54
  • >=7.0.12 <7.1
Fixed in
  • e220c1242a643d97102a79f09b7ef3aa31276961
  • cbb325bc150e8c0dbce004ac0e5516bcffc0de31
  • ab0678a0701ac4de499428dc1b321659bb74d272
  • 8010212197d4a3ee714f78ed77048d0b712ff925
  • 6610c6fe4b8936c232048e6049bf77c70a6f759c
  • 7.1
  • 6.18.54
  • 6.12.112
LinuxLinuxAffected
  • =7.1
Fixed in–

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.

References

Community reviews

Loading reviews…