Cloudanix VulnDB

CVE-2026-98246

None

CVSS

—

EPSS

0.2%

Published

Oct 6, 2026

CISA due date

—

Cloudanix analysis

Next patch cycle SSVC: Track

A timing flaw in Linux Bluetooth handling can let a device shutdown interfere with ongoing connection queries and crash the whole system.

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

What it actually does

Use-after-free in Bluetooth HCI sync: hci_dev_close_sync frees codec list entries without holding hdev->lock while sco_sock_getsockopt concurrently traverses the list under the lock, allowing a freed entry to be read.

Why it matters to the business

Linux Bluetooth systems may experience kernel crashes or memory corruption under concurrent device close and codec query workloads; low public exploit activity reduces immediate risk but still requires patching to maintain stability.

How an attack unfolds

An attacker triggers hci_dev_close_sync while a separate thread performs BT_CODEC getsockopt on an SCO socket; the close frees list entries after the query has fetched a pointer but before it dereferences the entry, causing slab-use-after-free.

How to fix it

Apply the upstream fix that acquires hdev->lock around hci_codec_list_clear in hci_dev_close_sync; rebuild and deploy the patched kernel across all affected Linux distributions.

How to confirm the fix worked

Recompile kernel with KASAN enabled, reproduce close+getsockopt interleaving, and confirm absence of slab-use-after-free reports referencing sco_sock_getsockopt and hci_codec_list_clear.

Typical attack path

  1. Open SCO socket and issue BT_CODEC getsockopt
  2. Concurrently trigger hci_dev_close_sync on the same hci device
  3. Interleave causes kfree of codec entry during active traversal
  4. Reader accesses freed memory leading to KASAN-detected UAF

How to detect it

Search kernel logs and crash dumps for KASAN slab-use-after-free reports citing sco_sock_getsockopt and hci_codec_list_clear; correlate with Bluetooth device close events in dmesg or audit logs.

  • BUG: KASAN: slab-use-after-free in sco_sock_getsockopt
  • Read of size 1 at addr.*hci_codec_list_clear
  • Allocated by task.*hci_codec_list_add.isra.0
  • Freed by task.*hci_dev_close_sync

What your security team should do

  • Prioritize kernel updates containing the hci_sync serialization fix within standard patching windows
  • Disable Bluetooth where not required to reduce attack surface
  • Monitor kernel logs for KASAN or slab corruption messages involving hci_codec_list_clear

The record

In the Linux kernel, the following vulnerability has been resolved: Bluetooth: hci_sync: Serialize local codec list cleanup hci_dev_close_sync() clears hdev->local_codecs after releasing hdev->lock. Codec list additions and both traversals in sco_sock_getsockopt() use that lock, but the close path does not. A close and BT_CODEC query can therefore interleave as follows: hci_dev_close_sync() sco_sock_getsockopt() hci_dev_lock() fetch codec entry hci_codec_list_clear() kfree(entry) read entry->id The reader then accesses an entry which the close path has freed. KASAN BUG: KASAN: slab-use-after-free in sco_sock_getsockopt+0xfa0/0xfe0 Read of size 1 at addr ffff8881001c3450 Call Trace: sco_sock_getsockopt+0xfa0/0xfe0 do_sock_getsockopt+0x537/0x7b0 __sys_getsockopt+0xf2/0x170 Allocated by task 92: hci_codec_list_add.isra.0+0x2c/0x440 hci_read_codec_capabilities+0x224/0x590 hci_read_supported_codecs+0x2c2/0x640 Freed by task 92: kfree+0x131/0x3c0 hci_codec_list_clear+0xd8/0x160 hci_dev_close_sync+0x92a/0xfa0 Take hdev->lock around the clear operation at its existing point in the close path. This makes the clear wait for active readers and prevents a new traversal until the list is empty without changing teardown ordering.

Affected packages

Ecosystem Package Introduced Fixed