Cloudanix VulnDB

CVE-2026-98735

None

CVSS

—

EPSS

0.2%

Published

Oct 18, 2026

CISA due date

—

Cloudanix analysis

Schedule a fix SSVC: Track

A flaw in Linux Bluetooth handling can let a local user crash the system or potentially run code by creating and breaking connections at the right moment.

Exploitation
Local Privilege
Attacker needs
Local User
Complexity
Moderate
Impact
Privilege Gain
Component
OS kernel
Class
Use After Free
Remediation
Upgrade
Effort
Medium
Patch risk
Low

What it actually does

Use-after-free in the Bluetooth HCI transmit path: hci_chan_sent selects a channel under RCU then drops the lock before accessing chan->conn and its packet queue; a concurrent disconnect on the request workqueue can run hci_conn_failed, l2cap_conn_del and hci_chan_del, freeing the channel before the scheduler resumes and updates transmit counters or submits packets.

Why it matters to the business

Linux systems using Bluetooth can experience kernel crashes, memory corruption, or potential local privilege escalation when Bluetooth connections are established or torn down, leading to denial of service or system compromise on affected devices.

How an attack unfolds

An attacker with local access triggers repeated L2CAP channel creation and forced disconnection (via timeout or explicit abort) while the HCI transmit workqueue is actively selecting and sending on the same channel; the race between channel teardown on the command sync workqueue and packet scheduling allows the freed channel object to be dereferenced, resulting in use-after-free.

How to fix it

Apply the upstream fix that holds the device mutex across channel selection and transmission in both ACL and LE schedulers; rebuild and deploy updated kernel packages containing the mutex serialization change for hci_core.

How to confirm the fix worked

Confirm the patch is present by inspecting hci_core.c for the added mutex acquisition around channel selection in hci_chan_sent and the schedulers; test by exercising concurrent connect/disconnect under load and verify absence of KASAN reports or crashes.

Typical attack path

  1. Establish L2CAP connection creating an hci_chan
  2. Trigger disconnect timeout or abort on the separate request workqueue
  3. Force hci_chan_del to unlink, synchronize_rcu and free the channel
  4. Resume hci_tx_work which dereferences the now-freed channel in hci_chan_sent
  5. Achieve slab use-after-free for crash or memory corruption

How to detect it

Search kernel logs and dmesg for KASAN slab-use-after-free reports naming hci_chan_sent or hci_tx_work; inspect workqueue traces showing hci_abort_conn_sync or l2cap_conn_del concurrent with transmit activity; review audit logs for unusual Bluetooth socket connect/disconnect patterns.

What your security team should do

  • Prioritize kernel updates on all Linux systems exposing Bluetooth
  • Disable Bluetooth when not required until patched
  • Monitor for kernel oops or KASAN reports involving hci_chan_sent or hci_tx_work
  • Apply defense-in-depth by restricting unprivileged local access

The record

In the Linux kernel, the following vulnerability has been resolved: Bluetooth: hci_core: Serialize ACL scheduling with channel deletion hci_chan_sent() selects a channel under RCU but drops the read lock before accessing chan->conn and returning the channel. The ACL and LE schedulers then use its packet queue and update its transmit counters without any protection against channel deletion. After TX selects a channel and releases RCU, a disconnect command timeout on the separate request workqueue can run hci_conn_failed() and l2cap_conn_del(). hci_chan_del() can then unlink the channel, complete synchronize_rcu(), purge its queue and free it before TX resumes. This causes use-after-free both in hci_chan_sent() and in its callers. KASAN reported: BUG: KASAN: slab-use-after-free in hci_chan_sent+0x892/0x9b0 Workqueue: hci0 hci_tx_work Call Trace: hci_chan_sent+0x892/0x9b0 hci_tx_work+0x5e6/0xb70 Allocated by task 91: hci_chan_create+0xe3/0x350 l2cap_conn_add.part.0+0x12/0xa30 l2cap_chan_connect+0x110d/0x1b60 l2cap_sock_connect+0x310/0x530 Freed by task 99: hci_chan_del+0x11f/0x170 l2cap_conn_del+0x4f1/0x800 l2cap_connect_cfm+0x88c/0xd30 hci_conn_failed+0x150/0x250 hci_abort_conn_sync+0x3e3/0x800 hci_cmd_sync_run+0x7e/0xc0 hci_abort_conn+0x105/0x1f0 disconnect_sync+0x157/0x290 hci_cmd_sync_work+0x13c/0x290 Hold the existing device mutex across channel selection and transmission in both schedulers to serialize them with channel teardown. Keep timeout handling outside the critical sections because hci_link_tx_to() acquires the same mutex. This also permits the transmit path to sleep, unlike extending the RCU read-side critical section across packet submission.

Affected packages

Ecosystem Package Introduced Fixed