Cloudanix VulnDB

CVE-2026-90255

High · 8.8

CVSS

8.8

EPSS

0.3%

Published

Sep 17, 2026

CISA due date

—

Cloudanix analysis

Next patch cycle SSVC: Track

A bug in how Linux handles certain Bluetooth connections can let a nearby attacker crash the computer or potentially take control of it.

Exploitation
Adjacent Network
Attacker needs
None
Complexity
Low
Impact
Full Compromise
Component
OS kernel
Class
Use After Free
Remediation
Patch
Effort
Medium
Patch risk
Low

What it actually does

Use-after-free and memory leak in Linux kernel Bluetooth HCI SCO setup: hci_setup_sync queues a conn_handle_t wrapper without a destroy callback, leaking the entry on cancellation via _hci_cmd_sync_cancel_entry or hci_cmd_sync_clear; the wrapper holds a bare hci_conn pointer that can be freed while queued, with hci_conn_del failing to match and dequeue it.

Why it matters to the business

Kernel memory corruption or crashes on systems using Bluetooth SCO profiles, potentially disrupting wireless audio/headset functionality and requiring reboots; high severity on multi-user or networked Linux devices with Bluetooth enabled.

How an attack unfolds

An attacker within Bluetooth range triggers repeated SCO connection setup attempts that are cancelled before completion, causing the context to remain queued with a dangling hci_conn reference; when the connection object is freed, subsequent access during dequeue or work execution leads to use-after-free, enabling memory corruption.

How to fix it

Update to a Linux kernel version containing the fix that adds a destroy callback to release both the wrapper and held hci_conn reference, and ensures submission failure and cancellation paths properly clean up; disable Bluetooth if unused.

How to confirm the fix worked

Confirm the kernel source contains the referenced changes (hold conn reference, destroy callback in hci_setup_sync, matching dequeue logic); test by exercising SCO setup/cancel sequences and verifying no leaks via kmemleak or slab poisoning; monitor for crashes in hci_conn_del or hci_cmd_sync paths.

Typical attack path

  1. Gain adjacent network proximity to target Bluetooth controller
  2. Initiate and cancel SCO/eSCO connection requests to exercise hci_setup_sync path
  3. Trigger hci_conn_del or controller unregister to free the underlying connection while the wrapper remains queued
  4. Force reuse or access of the freed hci_conn pointer via pending work or command sync handling

How to detect it

Inspect kernel logs for oops/panic traces referencing hci_conn_del, hci_setup_sync, hci_cmd_sync_cancel_entry or hci_sync; look for repeated Bluetooth SCO setup failures followed by memory-related crashes; use kernel ftrace or eBPF to monitor hci_cmd_sync_submit calls without matching destroy callbacks.

What your security team should do

  • Prioritize kernel updates on all Bluetooth-enabled Linux systems within 30 days given CVSS 8.8
  • Disable Bluetooth HCI and SCO profiles via kernel config or runtime if not required
  • Add kernel memory debugging (KASAN, kmemleak) to Bluetooth test suites
  • Monitor EPSS and exploit maturity for any increase in public PoCs

The record

In the Linux kernel, the following vulnerability has been resolved: Bluetooth: hci_conn: fix the SCO setup context lifetime hci_setup_sync() queues a conn_handle_t with a NULL destroy callback, so the context is only freed if hci_enhanced_setup_sync() actually runs. An entry that is cancelled instead is leaked, as _hci_cmd_sync_cancel_entry() does not release entry->data when there is no destroy callback, and hci_cmd_sync_clear() cancels every pending entry when the controller is unregistered. The context also stores a bare hci_conn pointer, so the connection can be freed while the work is queued. The dequeue in hci_conn_del() does not cover it either, as it matches on entry->data == conn and entry->data is the wrapper here. Same problem as commit 2f5d635ad590 ("Bluetooth: hci_sync: hold conn in hci_connect_acl/le_sync() callbacks"). Hold the connection and release both from a destroy callback. The submission failure path drops both, since hci_cmd_sync_submit() does not call the destroy callback when it fails to queue.

Affected packages

Ecosystem Package Introduced Fixed