Cloudanix VulnDB

CVE-2026-90253

None

CVSS

—

EPSS

0.2%

Published

Sep 17, 2026

CISA due date

—

Cloudanix analysis

Schedule a fix SSVC: Track

A bug in the Linux kernel's Bluetooth code can slowly use up memory that never gets freed, eventually making the system slower or unstable until it is restarted.

Exploitation
Local Privilege
Attacker needs
Local User
Complexity
Low
Impact
Denial Of Service
Component
OS kernel
Class
Memory Corruption
Remediation
Patch
Effort
Low
Patch risk
Low

What it actually does

A memory leak occurs in the Bluetooth MGMT subsystem when a mesh send cancel command is queued without a destroy callback; cancellation paths and controller unregistration fail to release the entry or the associated socket reference, causing permanent resource retention.

Why it matters to the business

Repeated Bluetooth management operations on affected kernels gradually consume kernel memory and hold socket references, which can degrade performance, exhaust limited resources on long-running systems, and complicate Bluetooth stack restarts until reboot.

How an attack unfolds

An attacker with local access triggers repeated mesh send and cancel sequences through the MGMT interface; each cancelled entry leaks memory and pins a socket reference that is never reclaimed, leading to gradual resource exhaustion without requiring remote network access.

How to fix it

Update the Linux kernel to a version containing the fix that supplies a destroy callback for the mesh send cancel command so that all cancellation and cleanup paths release the allocated entry and socket reference.

How to confirm the fix worked

Confirm the kernel source contains the destroy callback registration for the cancel command, verify that hci_cmd_sync_clear and _hci_cmd_sync_cancel_entry now release entries lacking a prior destroy callback, and test that repeated mesh send/cancel cycles no longer increase memory or socket reference counts.

Typical attack path

  1. Obtain local access or execute code on the target system
  2. Interact with the Bluetooth MGMT socket to issue mesh send commands
  3. Cancel those commands to trigger the leak path
  4. Repeat to accumulate leaked memory and pinned sockets
  5. Observe system degradation or socket exhaustion

How to detect it

Review kernel memory accounting and slab allocator statistics for growth in structures tied to Bluetooth MGMT pending commands; inspect logs for repeated hci_cmd_sync_cancel_entry activity and correlate with Bluetooth socket reference counts that fail to decrease after controller unregistration.

What your security team should do

  • Prioritize kernel updates on systems that expose the Bluetooth MGMT interface
  • Restrict unprivileged access to the Bluetooth management socket via permissions or SELinux/AppArmor policy
  • Monitor memory usage trends on Bluetooth-enabled hosts for unexpected growth correlated with MGMT activity

The record

In the Linux kernel, the following vulnerability has been resolved: Bluetooth: MGMT: free the mesh send cancel command when it is cancelled mesh_send_cancel() queues the pending command with a NULL destroy callback, so it is only freed if send_cancel() runs. A cancelled entry 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. Nothing else reclaims it either: mgmt_pending_new() does not put the command on hdev->mgmt_pending. The leak also pins the socket reference taken by mgmt_pending_new(), so the mgmt socket is never released. Free the command from a destroy callback.

Affected packages

Ecosystem Package Introduced Fixed