CVE-2026-53251

What it actually does

This flaw is a reference-count leak in the Linux kernel Bluetooth ISO path. The affected function obtains a reference to a Bluetooth HCI device through hci_get_route(), which internally increments the device reference count, but the ISO BIG synchronization path can return without releasing that reference. Repeated triggering can keep Bluetooth device objects artificially pinned, causing resource leakage, failed device teardown, degraded Bluetooth behavior, or kernel memory/resource exhaustion over time. The primary impact is denial of service rather than code execution or privilege escalation.

Why it matters to the business

Systems with Bluetooth enabled may experience instability, degraded Bluetooth service, inability to cleanly remove or reset Bluetooth adapters, or broader system resource pressure if the vulnerable path is repeatedly triggered. The current public exploitation signal is low: EPSS is 0.00122, no known exploitation is listed in CISA KEV, and exploit maturity is reported as none. Because this is a kernel-level flaw, organizations should still remediate through normal kernel maintenance cycles, with higher priority for laptops, workstations, kiosks, embedded Linux systems, and products that actively use Bluetooth LE Audio or ISO features.

How an attack unfolds

An attacker must be able to reach the vulnerable Bluetooth ISO synchronization code path. In practical terms, this most likely requires local access to create or manipulate Bluetooth ISO activity, or a scenario where the host is configured to interact with nearby Bluetooth LE Audio broadcast/ISO functionality. The attacker repeatedly causes ISO BIG synchronization attempts that call hci_get_route(). Each attempt can leave an HCI device reference unreleased. Over time, the leaked references accumulate, preventing normal cleanup of Bluetooth device state and potentially consuming kernel resources. The result is a denial-of-service condition such as Bluetooth subsystem malfunction, inability to unload or reset the adapter, persistent device references, or system degradation under sustained triggering. There is no public indication that this vulnerability is being used by named threat actors or ransomware campaigns.

How to fix it

Apply a kernel update from the Linux distribution, appliance vendor, or device manufacturer that includes the Bluetooth ISO fix for this issue. Because no fixed package versions were provided in the input, validate remediation against vendor advisories or kernel changelogs referencing CVE-2026-53251 or the fix for releasing the hdev reference in iso_conn_big_sync. Where immediate patching is not possible, reduce exposure by disabling Bluetooth on systems that do not require it, disabling or restricting Bluetooth LE Audio/ISO features where supported, limiting local user access to Bluetooth management capabilities, and preventing untrusted users from running workloads on systems with Bluetooth enabled. For embedded or appliance builds, backport the upstream fix so every hci_get_route()/hci_dev_hold() reference acquired in the ISO BIG sync path is paired with hci_dev_put() on all success and error exits.

How to confirm the fix worked

Confirm the running kernel has been updated to a vendor-fixed build using uname -r and the distribution package manager or vendor advisory metadata. For source-based validation, review the Bluetooth ISO implementation and verify that the iso_conn_big_sync path releases the HCI device reference with hci_dev_put() on all return paths after hci_get_route() succeeds. Confirm that Bluetooth adapters can be reset, removed, or the Bluetooth module stack can be unloaded and reloaded without hanging or leaving persistent device references. In test environments, exercise Bluetooth ISO/BIG synchronization behavior before and after the patch and monitor kernel memory use, Bluetooth device reference behavior, and kernel logs for cleanup failures. If Bluetooth is not required, validate mitigation by confirming Bluetooth controllers are disabled, blocked, or absent using tools such as rfkill, bluetoothctl, systemctl status bluetooth, and kernel module state checks.

Typical attack path

1. Identify a Linux system with Bluetooth enabled and a kernel build containing the vulnerable Bluetooth ISO code.
2. Gain the ability to exercise Bluetooth ISO/BIG synchronization functionality, such as through local Bluetooth socket/API access or a Bluetooth workflow that reaches the ISO sync path.
3. Repeatedly initiate ISO BIG synchronization attempts that cause hci_get_route() to return an HCI device reference.
4. Allow the vulnerable error or normal return paths to exit without releasing the HCI device reference.
5. Accumulate leaked references until Bluetooth device cleanup, adapter reset, or system resources are impaired.
6. Use the resulting Bluetooth subsystem failure or resource exhaustion as a denial-of-service condition.

How to detect it

There are no known attacker-specific indicators or public exploit artifacts for this vulnerability. Detection should focus on signs of possible abuse or stress of the vulnerable Bluetooth ISO path: unusual bursts of Bluetooth ISO or LE Audio activity, repeated Bluetooth adapter resets, failures to remove or reset HCI devices, kernel warnings involving Bluetooth cleanup, unexplained kernel memory pressure on Bluetooth-enabled systems, and local processes repeatedly interacting with Bluetooth sockets or management APIs. Useful log sources include kernel logs from dmesg or journald, Bluetooth daemon logs, audit logs for local process execution, endpoint telemetry showing Bluetooth-related tools or custom binaries, and eBPF/kprobe telemetry if available. For deeper investigation, instrument hci_get_route(), hci_dev_hold(), hci_dev_put(), and iso_conn_big_sync to identify repeated calls where references are not balanced. Because exploitation may not produce distinctive log messages, absence of logs does not prove absence of exposure.

What your security team should do

• Inventory Linux systems where Bluetooth is enabled, especially laptops, workstations, kiosks, embedded devices, and systems using Bluetooth LE Audio features.
• Prioritize kernel updates for Bluetooth-enabled systems during the next regular patch cycle; expedite for shared-user, kiosk, or physically exposed systems.
• If patching is delayed, disable Bluetooth on systems that do not have a business requirement for it.
• Restrict local users and applications from unnecessary Bluetooth management or raw Bluetooth access where platform controls allow it.
• Monitor for abnormal Bluetooth subsystem instability, repeated adapter resets, failed device removal, kernel memory pressure, or unexplained hangs involving Bluetooth services.
• Track vendor advisories for fixed kernel package versions because the affected product and fixed-version list is not enumerated here.
• Do not treat this as an active exploitation emergency based on current intelligence: it is not in CISA KEV, has no known ransomware association, and has very low EPSS, but still remediate because it affects kernel reliability.