CVE-2026-53252: Linux Kernel Bluetooth HCI Memory Leak—Mitigation & Patch Guide

Technical summary

CVE-2026-53252 is a memory leak vulnerability in the Linux kernel's Bluetooth HCI (Host Controller Interface) device allocation and cleanup path. The issue originates in hci_alloc_dev(), which initializes an SRCU struct early in device initialization. Under normal operation, hci_release_dev() would clean this up via cleanup_srcu_struct(). However, when initialization fails before hci_register_dev() completes, the HCI_UNREGISTER flag is never set. Subsequently, when the device reference count reaches zero, bt_host_release() checks this flag; finding it unset, the code takes a fallback path that directly calls kfree(hdev), completely bypassing hci_release_dev(). This causes the SRCU struct and its associated per-CPU memory to remain allocated indefinitely. The fix involves explicitly invoking cleanup_srcu_struct() in the unregistered device cleanup branch before freeing the device structure.

Business impact

On systems with frequently failing Bluetooth device initialization—such as those with unstable hardware, driver issues, or container/VM environments where Bluetooth is repeatedly probed and fails—this leak can accumulate and deplete kernel memory over time. Sustained memory leaks can trigger out-of-memory (OOM) conditions, system slowdowns, or unexpected kernel crashes. Organizations relying on Bluetooth connectivity or running Bluetooth-heavy deployments (e.g., IoT gateways, embedded systems) should prioritize this fix to maintain long-term system stability. The risk is primarily operational rather than security-critical, but it can enable indirect denial of service if an attacker can repeatedly trigger Bluetooth device failures.

Affected systems

All versions of the Linux kernel are affected. The vulnerability exists in the core Bluetooth HCI subsystem, which is present in virtually all Linux distributions and deployments, from mainline kernels to embedded and cloud environments. Any system with Bluetooth support compiled in or as a module is potentially vulnerable if device initialization can fail.

Exploitability

Exploitability requires local access to trigger repeated Bluetooth device initialization failures. An unprivileged user can typically initiate Bluetooth device probes or unbind/rebind operations, making it accessible without root privileges on many systems. However, practical exploitation depends on the availability of userspace tools to manipulate Bluetooth devices and the ability to repeatedly cause initialization failures. The leak is deterministic and will accumulate with each failed initialization, so a motivated attacker can reliably cause memory exhaustion through repeated probe attempts. There is no evidence of active exploitation in the wild.

Remediation

Update the Linux kernel to a patched version that includes the fix for CVE-2026-53252. The fix is minimal and focused: it adds an explicit cleanup_srcu_struct() call in the fallback cleanup path within bt_host_release() to ensure SRCU resources are released even when hci_release_dev() is bypassed. Verify the specific kernel version against your distribution's advisory and Linux upstream kernel repositories.

Patch guidance

Coordinate with your Linux distribution to obtain and deploy a patched kernel version. Most major distributions (Red Hat, Debian, Ubuntu, SUSE, etc.) will issue kernel updates as part of their regular security patching cycles. For systems running upstream or mainline kernels, pull the latest stable or LTS release containing this fix. Validate the patch commit in your kernel source or distribution advisory before deployment. Testing in a non-production environment is recommended, especially for systems with active Bluetooth workloads.

Detection guidance

Monitor kernel memory usage and look for gradual growth in memory consumption, particularly on systems where Bluetooth device initialization frequently fails or where Bluetooth devices are probed multiple times. Examine kernel logs for repeated Bluetooth initialization errors or device probe failures. Use tools like 'dmesg', 'journalctl', or per-CPU memory tracking utilities to correlate memory leaks with Bluetooth events. On affected kernels, enabling SRCU debugging or memory sanitizers (if feasible in production) may provide earlier warnings. Post-patch, verify that memory no longer accumulates during repeated Bluetooth device probe/removal cycles.

Why prioritize this

Although the CVSS score is moderate (5.5 MEDIUM), this vulnerability presents a practical denial-of-service vector that can silently degrade system availability over time. For environments where Bluetooth is actively used or where hardware/driver issues cause frequent initialization failures, the cumulative impact can be significant. The fix is low-risk and straightforward, making it a good candidate for timely patching. However, systems without Bluetooth functionality or in stable deployments with minimal device initialization churn face lower immediate risk.

Risk score, explained

The CVSS:3.1 score of 5.5 MEDIUM reflects a local attack vector requiring privileges to trigger (or user interaction to cause device failures), no impact on confidentiality or integrity, but a high impact on availability through memory exhaustion. The attack complexity is low once initialization failures occur, and the user interaction requirement is low. The score appropriately captures that this is a denial-of-service rather than a data compromise threat, but also recognizes the practical cumulative danger of resource leaks.

Frequently asked questions