CVE-2026-53252

What it actually does

This is a Linux kernel resource-leak flaw in the Bluetooth HCI device allocation and teardown path. If Bluetooth HCI UART initialization fails before hci_register_dev() completes, the device is freed through an unregistered-device fallback path that previously skipped cleanup_srcu_struct(). The result is a leak of SRCU per-CPU memory allocated during hci_alloc_dev(). The primary technical impact is kernel memory exhaustion over repeated failed Bluetooth HCI UART initialization attempts. The issue is best characterized as a denial-of-service/resource-exhaustion condition, not a known code-execution or privilege-escalation primitive based on the provided details.

Why it matters to the business

Systems using affected Linux kernels with Bluetooth HCI UART support enabled could become unstable or unavailable if the leak is repeatedly triggered, especially on devices with limited memory or embedded/edge systems where Bluetooth hardware is common. Operational effects may include degraded performance, kernel memory pressure, service disruption, or eventual reboot/panic due to memory exhaustion. Current public exploitation signals are low: EPSS is 0.0013, the issue is not in CISA KEV, is not associated with ransomware, and no exploit maturity is reported. Even so, organizations with large Linux fleets or Bluetooth-enabled embedded products should remediate through normal kernel update cycles because kernel resource leaks can accumulate into availability incidents.

How an attack unfolds

An attacker must be able to cause repeated Bluetooth HCI UART initialization failures on an affected kernel. In practical terms, this may require local access, administrative capability to load or interact with Bluetooth/HCI UART components, control over attached Bluetooth UART hardware, or an environment where an untrusted or malfunctioning peripheral can repeatedly trigger probe/configuration failures. Each failed initialization path allocates SRCU per-CPU memory in hci_alloc_dev() and, on vulnerable kernels, frees the HCI device without releasing that SRCU structure. By repeating the failure condition many times, the attacker can gradually consume kernel per-CPU memory until the system experiences memory pressure, degraded performance, or denial of service. There is no indication from the provided intelligence that this flaw enables arbitrary code execution, data theft, or privilege escalation.

How to fix it

Apply a vendor-supplied Linux kernel update that includes the Bluetooth fix for the hci_alloc_dev()/bt_host_release() error path, specifically ensuring the unregistered-device fallback path calls cleanup_srcu_struct() before freeing the HCI device. Because no affected product list or exact fixed package versions were provided, use the relevant distribution, appliance, or kernel vendor advisory to identify the fixed kernel build. Where immediate patching is not possible, reduce exposure by disabling Bluetooth if not required, preventing the hci_uart module from loading, limiting physical access to systems with UART-attached Bluetooth controllers, and restricting administrative ability to repeatedly load/unload or reconfigure Bluetooth HCI components. Embedded and edge deployments should prioritize firmware or kernel refreshes where Bluetooth hardware is enabled by default.

How to confirm the fix worked

Confirm the running kernel is updated to a build containing the fix, either by checking the distribution/vendor advisory, reviewing the kernel changelog for the Bluetooth SRCU cleanup fix, or verifying the source contains cleanup_srcu_struct() in the unregistered branch of bt_host_release(). Validate that Bluetooth HCI UART support is disabled where it is not needed by checking loaded modules and kernel configuration. On systems expected to use Bluetooth, monitor that repeated HCI UART initialization failures no longer cause persistent per-CPU memory growth. After patching, confirm the system has booted into the fixed kernel, not merely installed it, and that old vulnerable kernels are not still used by bootloader defaults or rollback images.

Typical attack path

1. Identify a Linux system running an affected kernel with Bluetooth HCI UART support present or loadable.
2. Gain the ability to influence Bluetooth HCI UART initialization, such as through local administrative actions, driver/module interaction, or attached UART Bluetooth hardware behavior.
3. Trigger an early failure during Bluetooth HCI UART device initialization before hci_register_dev() completes.
4. Repeat the failed initialization sequence to leak SRCU per-CPU memory each time.
5. Cause cumulative kernel memory pressure that can degrade system performance, disrupt Bluetooth/kernel services, or produce a denial-of-service condition.

How to detect it

Detection should focus on evidence of repeated Bluetooth HCI UART initialization failures followed by kernel memory pressure, rather than classic malware indicators. Review kernel logs from journald, dmesg, syslog, and persistent crash logs for recurring Bluetooth/HCI UART probe, attach, or registration failures. Correlate those events with rising memory consumption, per-CPU memory growth, out-of-memory killer activity, kernel warnings, soft lockups, unexpected Bluetooth service restarts, or unexplained reboots. On systems using auditd or endpoint telemetry, look for repeated local execution of Bluetooth management or attachment utilities such as btattach, hciattach, hciconfig, bluetoothctl, rfkill, or repeated modprobe/rmmod activity involving hci_uart, bluetooth, btqca, btrtl, btintel, or related modules. Because no public exploit strings, web indicators, threat actor procedures, or ransomware usage are provided, treat these as behavioral indicators of possible triggering or stress testing rather than definitive compromise indicators.

• hci_uart
• hci_alloc_dev
• bt_host_release
• cleanup_srcu_struct
• Bluetooth: hci
• Bluetooth: HCI UART
• btattach
• hciattach
• hciconfig
• bluetoothctl
• modprobe hci_uart
• rmmod hci_uart
• Out of memory
• oom-killer
• Memory allocation failure
• percpu allocation failed

What your security team should do

• Inventory Linux systems with Bluetooth enabled, hci_uart support loaded, or UART-attached Bluetooth controllers, prioritizing embedded, kiosk, mobile, industrial, and edge devices.
• Patch affected kernels through the normal vendor update process; prioritize systems where Bluetooth is enabled and memory headroom is limited.
• If Bluetooth is not required, disable it and block loading of Bluetooth/HCI UART kernel modules as a compensating control.
• Review recent kernel logs for repeated Bluetooth HCI UART initialization failures combined with increasing memory pressure or unexplained reboots.
• Ensure vulnerability management tracks kernel runtime versions, not only installed package versions, because remediation requires booting into the fixed kernel.
• For appliance or firmware-based products, obtain fixed firmware/kernel images from the vendor and confirm the fix is included in the shipped kernel.