---
id: CVE-2026-98735
title: 'Bluetooth: hci_core: Serialize ACL scheduling with channel deletion'
summary: |-
  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…
severity: none
vendor: Linux
product: Linux
affected:
  - >-
    Linux >= 3eff45eaf81780dad25c167bbaafa7d25ae407da <
    51f95ea451f25d7e3f048c0f438f04fa74688aae
  - >-
    Linux >= 3eff45eaf81780dad25c167bbaafa7d25ae407da <
    86e9708f9d19a7f1bd5dc9c1652d07707f79f5bd
  - >-
    Linux >= 3eff45eaf81780dad25c167bbaafa7d25ae407da <
    4fda8f0abeea9929036446d89a476fb8298abcb0
  - >-
    Linux >= 3eff45eaf81780dad25c167bbaafa7d25ae407da <
    f4845ab191a4f686a5da481fbba90ed73bb693b0
  - Linux 3.3
published: '2026-10-18'
updated: '2026-10-18'
sourceUpdated: '2026-10-18T15:47:13.062Z'
source: CVEORG
sourceUrl: 'https://www.cve.org/CVERecord?id=CVE-2026-98735'
references:
  - url: 'https://git.kernel.org/stable/c/51f95ea451f25d7e3f048c0f438f04fa74688aae'
  - url: 'https://git.kernel.org/stable/c/86e9708f9d19a7f1bd5dc9c1652d07707f79f5bd'
  - url: 'https://git.kernel.org/stable/c/4fda8f0abeea9929036446d89a476fb8298abcb0'
  - url: 'https://git.kernel.org/stable/c/f4845ab191a4f686a5da481fbba90ed73bb693b0'
tags:
  - cve.org
ingestedAt: '2026-10-18T16:47:32.504Z'
---

## Overview

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

- `Linux >= 3eff45eaf81780dad25c167bbaafa7d25ae407da < 51f95ea451f25d7e3f048c0f438f04fa74688aae`
- `Linux >= 3eff45eaf81780dad25c167bbaafa7d25ae407da < 86e9708f9d19a7f1bd5dc9c1652d07707f79f5bd`
- `Linux >= 3eff45eaf81780dad25c167bbaafa7d25ae407da < 4fda8f0abeea9929036446d89a476fb8298abcb0`
- `Linux >= 3eff45eaf81780dad25c167bbaafa7d25ae407da < f4845ab191a4f686a5da481fbba90ed73bb693b0`
- `Linux 3.3`

## Remediation

Refer to the linked advisories for vendor-supplied fixes and affected version ranges.