Cloudanix VulnDB

CVE-2026-98632

None

CVSS

—

EPSS

0.2%

Published

Oct 18, 2026

CISA due date

—

Cloudanix analysis

Schedule a fix SSVC: Track

A flaw in Linux Bluetooth code can let an attacker crash the system or potentially run malicious code by interfering with wireless mesh network operations.

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

A use-after-free occurs when a mesh_tx object is freed via mesh_send_complete during send_cancel but a raw pointer to it remains queued in hdev->cmd_sync_work_list via mesh_next; later execution of mesh_send_sync and mesh_send_start_complete by hci_cmd_sync_work dereferences the freed memory.

Why it matters to the business

Linux systems using Bluetooth mesh can experience kernel crashes, memory corruption, or potential code execution, increasing downtime and security risk for devices that rely on Bluetooth connectivity.

How an attack unfolds

An attacker initiates a mesh transmission, forces it onto the cmd_sync_work_list, then triggers cancellation so the object is freed while the work item still holds the pointer; when the work queue processes the stale entry the use-after-free is triggered.

How to fix it

Apply the upstream kernel fix that calls hci_cmd_sync_dequeue on mesh_send_sync before completing the object and that advances the queue safely after cancellation; rebuild and deploy the patched kernel on all affected systems.

How to confirm the fix worked

Confirm the fix is present by inspecting the Bluetooth mgmt code for hci_cmd_sync_dequeue usage in send_cancel and the conditional mesh_next call in mesh_send_start_complete; test that mesh cancellation no longer produces use-after-free warnings.

Typical attack path

  1. Start a Bluetooth mesh transmission that queues a mesh_tx entry
  2. Invoke send_cancel to remove and free the mesh_tx from the pending list
  3. Leave the corresponding entry on the cmd_sync_work_list
  4. Allow hci_cmd_sync_work to execute the dangling mesh_send_sync callback

How to detect it

Search kernel logs and crash dumps for use-after-free reports involving mesh_tx, hci_cmd_sync_work, mesh_send_sync, or mesh_send_start_complete; correlate with Bluetooth mesh activity in the hours before any panic.

What your security team should do

  • Prioritize kernel updates for Bluetooth mesh users within the next maintenance window
  • Disable Bluetooth mesh functionality where it is not required
  • Monitor kernel oops and KASAN reports for hci_cmd_sync_work and mesh_send symbols
  • Review downstream dependent packages for backported fixes

The record

In the Linux kernel, the following vulnerability has been resolved: Bluetooth: mgmt: Dequeue pending mesh_send_sync entries on cancel In send_cancel(), pending mesh_tx objects are removed from the hdev->mesh_pending list and freed via mesh_send_complete(). However, if a mesh transmission was already queued onto hdev->cmd_sync_work_list via mesh_next(), the queued entry retains a raw pointer to mesh_tx. When hci_cmd_sync_work later processes the entry, it attempts to execute mesh_send_sync and its destroy callback mesh_send_start_complete using the already freed mesh_tx pointer, leading to a use-after-free. Fix this by invoking hci_cmd_sync_dequeue() for mesh_send_sync on the target mesh_tx before completing it. If the entry is found and dequeued, its destroy callback will complete and free the object; otherwise, mesh_send_complete() is called directly. Additionally, ensure the transmission queue advances after cancellation or errors. In mesh_send_start_complete(), call mesh_next() on error unless err is -ECANCELED, because hci_cmd_sync_dequeue() holds hdev->cmd_sync_work_lock and calling mesh_next() synchronously would deadlock. Instead, advance the queue in send_cancel() once the lock is released and if no transmission is in progress.

Affected packages

Ecosystem Package Introduced Fixed