CVE-2026-64406 in Linux
Summary
by MITRE • 07/25/2026
In the Linux kernel, the following vulnerability has been resolved:
Bluetooth: fix UAF in bt_accept_dequeue()
bt_accept_get() takes a temporary reference before dropping the accept queue lock. bt_accept_dequeue() currently drops that reference before bt_accept_unlink(), leaving only the queue reference.
bt_accept_unlink() drops the queue reference. The subsequent sock_hold() therefore accesses freed memory if it was the final reference, as observed by KASAN during listening L2CAP socket cleanup.
Retain the temporary queue-walk reference through unlink and hand it to the caller on success. Drop it explicitly on the closed and not-yet-connected paths.
If you want to get the best quality for vulnerability data then you always have to consider VulDB.
Analysis
by VulDB Data Team • 07/26/2026
This vulnerability represents a use-after-free condition in the Linux kernel's Bluetooth subsystem specifically affecting the bt_accept_dequeue() function within the L2CAP (Logical Link Control and Adaptation Protocol) implementation. The flaw occurs during the cleanup process of listening L2CAP sockets where improper reference counting leads to memory corruption. The issue stems from the sequence of operations in the Bluetooth socket handling code where temporary references are not properly managed across function calls, creating a window where freed memory can be accessed.
The technical root cause involves the interaction between bt_accept_get(), bt_accept_dequeue(), and bt_accept_unlink() functions within the kernel's Bluetooth stack. When bt_accept_get() acquires a temporary reference before releasing the accept queue lock, the subsequent bt_accept_dequeue() function drops this temporary reference prematurely before calling bt_accept_unlink(). This premature release leaves only the queue reference remaining, which when subsequently processed by bt_accept_unlink() causes sock_hold() to access memory that has already been freed. The vulnerability manifests as a kernel memory corruption issue that KASAN (Kernel Address Sanitizer) detected during normal socket cleanup operations.
The operational impact of this vulnerability is significant as it represents a potential kernel memory corruption flaw that could lead to system instability, crashes, or in worst-case scenarios, privilege escalation opportunities. Attackers could potentially exploit this condition by creating specific Bluetooth socket states that trigger the corrupted reference counting sequence, leading to denial of service or arbitrary code execution within kernel space. The vulnerability affects systems running Linux kernels with Bluetooth support and particularly impacts systems using L2CAP sockets in listening mode.
This vulnerability maps directly to CWE-416 Use After Free and CWE-1287 Kernel Memory Corruption, both of which are categorized under the broader class of memory safety issues in kernel space. From an ATT&CK perspective, this represents a privilege escalation vector through kernel memory corruption (T1068) that could enable attackers to gain elevated privileges on affected systems. The vulnerability demonstrates poor reference counting practices in kernel code where temporary references are not properly maintained across function boundaries during concurrent access scenarios.
The recommended mitigations include applying the upstream kernel patch that modifies the reference handling logic to retain the temporary queue-walk reference through the unlink process and explicitly drop it on both closed and not-yet-connected paths. This ensures proper reference counting throughout the socket cleanup lifecycle, preventing the premature release of memory that leads to the use-after-free condition. Organizations should prioritize applying kernel updates from their respective distributions and monitor for any related security advisories from Linux kernel maintainers or security vendors. System administrators should also consider implementing additional monitoring for kernel memory corruption indicators during Bluetooth socket operations and ensure proper kernel hardening configurations are in place to limit potential exploitation surfaces.