Cloudanix VulnDB

CVE-2026-98297

None

CVSS

—

EPSS

0.2%

Published

Oct 6, 2026

CISA due date

—

Cloudanix analysis

Schedule a fix SSVC: Track

A timing problem in the Linux kernel's Bluetooth code can cause wireless connections to break when a device is being turned off at the same moment data is being sent.

Exploitation
Local Privilege
Attacker needs
Local User
Complexity
Moderate
Impact
Denial Of Service
Component
OS kernel
Class
Race Condition
Remediation
Upgrade
Effort
Medium
Patch risk
Low

What it actually does

Race condition allows hci_send_acl, hci_send_sco and hci_send_iso to call queue_work on tx_work after hci_dev_close_sync has marked the workqueue __WQ_DRAINING, causing __queue_work to emit a warning and drop the work item.

Why it matters to the business

Bluetooth connections may fail or drop unexpectedly during device shutdown races, producing kernel warnings and reducing reliability of wireless peripherals on affected Linux systems.

How an attack unfolds

An attacker with local access triggers concurrent L2CAP/SCO/ISO socket writes while a Bluetooth device is being closed, forcing the send path to attempt queueing after the drain guard is set and causing the work item to be silently dropped.

How to fix it

Update the Linux kernel to a version containing the hci_sched_tx helper and the associated drain checks for tx_work producers.

How to confirm the fix worked

Confirm presence of the hci_sched_tx helper and that hci_send_acl, hci_send_sco and hci_send_iso route through it before queueing; verify the HCI_CMD_DRAIN_WORKQUEUE guard is evaluated in those paths.

Typical attack path

  1. Open Bluetooth device and establish L2CAP/SCO/ISO channel
  2. Trigger hci_dev_close_sync from one thread or process
  3. Race with socket sendmsg from another thread while drain flag is active
  4. Observe warning in kernel log and dropped tx_work

How to detect it

Search kernel logs for the string "cannot queue %ps on wq %s" together with call traces containing l2cap_chan_send, l2cap_sock_sendmsg or hci_send_acl during device close events.

  • cannot queue %ps on wq %s
  • WARNING: CPU:.*PID:.*at kernel/workqueue.c:2352 __queue_work
  • l2cap_chan_send.*l2cap_sock_sendmsg.*hci_send_acl

What your security team should do

  • Apply the upstream Bluetooth hci_core fix at the next kernel update window
  • Monitor kernel logs for the __queue_work drain warning on systems running Bluetooth
  • Disable unnecessary Bluetooth profiles where feasible until patched

The record

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 packages

Ecosystem Package Introduced Fixed