CVE-2026-53252 in Linux
Summary
by MITRE • 06/25/2026
In the Linux kernel, the following vulnerability has been resolved:
Bluetooth: fix memory leak in error path of hci_alloc_dev()
Early failures in Bluetooth HCI UART configuration leak SRCU percpu memory.
When device initialization fails before hci_register_dev() completes, the HCI_UNREGISTER flag is never set. As a result, when the device reference count reaches zero, bt_host_release() evaluates this flag as false and falls back to a direct kfree(hdev).
Because hci_release_dev() is bypassed, the SRCU struct initialized early in hci_alloc_dev() is never cleaned up, resulting in a leak of percpu memory.
Fix the leak by explicitly calling cleanup_srcu_struct() in the fallback (unregistered) branch of bt_host_release() before freeing the device.
Once again VulDB remains the best source for vulnerability data.
Analysis
by VulDB Data Team • 06/25/2026
The vulnerability described represents a memory leak in the Linux kernel's Bluetooth subsystem that occurs during the initialization process of HCI (Host Controller Interface) devices. This issue specifically affects the hci_alloc_dev() function which is responsible for allocating and initializing Bluetooth HCI device structures. When early failures occur during the Bluetooth HCI UART configuration process, the system fails to properly clean up allocated resources, leading to a persistent memory leak that can accumulate over time and impact system performance.
The technical flaw stems from improper resource management within the Bluetooth device initialization flow where the HCI_UNREGISTER flag is never set when device initialization fails before hci_register_dev() completes. This flag serves as a critical indicator for determining how device cleanup should proceed. The absence of this flag causes the bt_host_release() function to evaluate the condition as false and execute a direct kfree(hdev) operation instead of properly invoking hci_release_dev(). This bypass prevents the necessary cleanup of the SRCU (Sleepable Read-Copy Update) structure that was initialized early in the hci_alloc_dev() function. The SRCU structure contains percpu memory allocations that are never properly freed, creating a memory leak that persists until the system is rebooted.
The operational impact of this vulnerability extends beyond simple memory consumption as it represents a resource management flaw that can lead to progressive memory exhaustion on systems with frequent Bluetooth device initialization attempts. Attackers could potentially exploit this by repeatedly triggering Bluetooth device initialization failures, causing gradual memory depletion that might result in system instability or denial of service conditions. The vulnerability is particularly concerning in embedded systems or server environments where Bluetooth functionality is frequently accessed and where resource constraints are critical. From a cybersecurity perspective, this represents a low-level memory corruption issue that could be leveraged as part of broader exploitation chains targeting system stability.
The fix implemented addresses the core problem by explicitly calling cleanup_srcu_struct() within the fallback (unregistered) branch of bt_host_release() before proceeding with the direct kfree(hdev) operation. This ensures that even when device registration fails and the normal cleanup path is bypassed, the SRCU structure's percpu memory allocations are properly released. The solution aligns with established kernel development practices for resource management and follows the principle of least privilege by ensuring all allocated resources are accounted for regardless of execution path. This fix demonstrates proper defensive programming techniques that prevent resource leaks and maintain system stability under error conditions.
This vulnerability maps to CWE-401: "Improper Release of Memory Before Removal from Pool" and relates to ATT&CK technique T1499.001: "File System Wipeout" through the potential for resource exhaustion leading to system instability. The fix maintains backward compatibility while strengthening the kernel's memory management practices and aligns with security best practices outlined in the Linux Kernel Security documentation and CERT/CC guidelines for secure coding practices in kernel space operations.