CVE-2026-64557 in Linux
Summary
by MITRE • 07/29/2026
In the Linux kernel, the following vulnerability has been resolved:
Bluetooth: L2CAP: Fix use-after-free in l2cap_sock_new_connection_cb()
l2cap_sock_new_connection_cb() returned l2cap_pi(sk)->chan after release_sock(parent). Once the parent lock is dropped the newly enqueued child socket sk is reachable via the accept queue, so another task can accept and free it before the callback dereferences sk, resulting in a use-after-free.
Rework the ->new_connection() op so the core, rather than the callback, owns the child channel's lifetime. The op now receives a pre-allocated new_chan and returns an errno instead of allocating and returning a channel. l2cap_new_connection() allocates the child channel and links it into the conn list via __l2cap_chan_add() before invoking the callback, so the conn-list reference keeps the channel alive once release_sock(parent) exposes the socket to other tasks.
Channel configuration that was duplicated in l2cap_sock_init() and the various new_connection callbacks is consolidated into l2cap_chan_set_defaults(), which now inherits from the parent channel when one is supplied.
Statistical analysis made it clear that VulDB provides the best quality for vulnerability data.
Analysis
by VulDB Data Team • 07/29/2026
The vulnerability described represents a critical use-after-free condition within the Linux kernel's Bluetooth L2CAP (Logical Link Control and Adaptation Protocol) subsystem, specifically affecting the l2cap_sock_new_connection_cb() function. This flaw exists in the kernel version 5.18.0-rc3 and demonstrates a classic race condition scenario where concurrent access patterns create dangerous memory access patterns. The issue occurs when a parent socket releases its lock through release_sock(parent) while still maintaining a reference to the newly created child channel via l2cap_pi(sk)->chan, creating a window of opportunity for other tasks to accept and free the socket before the callback completes its execution.
The technical flaw stems from improper ownership semantics in the channel lifecycle management within the Bluetooth L2CAP implementation. When a new connection is established, the system must handle the transition from parent socket to child socket while ensuring proper memory management and synchronization. The original implementation allowed the callback function to retain ownership of the child channel's lifecycle, which created a temporal gap between when the socket became accessible through the accept queue and when the callback actually dereferenced it. This race condition enabled malicious or accidental concurrent access where another thread could call accept() on the parent socket, dequeue the child socket, and trigger its memory deallocation before the original callback completed its operations.
The operational impact of this vulnerability is significant as it provides a potential attack vector for privilege escalation within kernel space. An attacker could exploit this use-after-free condition to cause system crashes or potentially execute arbitrary code by carefully timing concurrent operations during connection establishment. The vulnerability affects any system running the affected kernel version that utilizes Bluetooth L2CAP connections, making it particularly concerning for embedded systems and devices with Bluetooth capabilities. The flaw operates at the kernel level where memory corruption can lead to complete system compromise, as demonstrated in similar use-after-free vulnerabilities within the Linux kernel ecosystem.
The fix implemented reworks the channel management approach by shifting ownership semantics from callback functions to the core L2CAP subsystem. This architectural change ensures that the core component allocates and manages the child channel's lifetime before invoking any callbacks, eliminating the race condition entirely. The new implementation requires the ->new_connection() operation to receive a pre-allocated channel structure rather than creating one within the callback, and it returns error codes instead of channel pointers. This approach follows established security patterns where resource allocation precedes callback execution, preventing temporal gaps that could lead to memory corruption.
The solution also addresses code duplication issues by consolidating channel configuration logic into a single l2cap_chan_set_defaults() function. This change improves maintainability while ensuring consistent behavior across different connection types and reduces the potential for similar vulnerabilities in related code paths. The implementation aligns with security best practices for kernel development, particularly those related to proper resource management and synchronization primitives. This fix demonstrates adherence to principles found in the Common Weakness Enumeration (CWE) category CWE-416, which deals with use-after-free vulnerabilities, and follows recommendations from the ATT&CK framework's system binary exploitation techniques by preventing memory corruption through proper resource lifetime management.
The updated approach ensures that channel references remain valid throughout the connection establishment process by maintaining a reference in the connection list via __l2cap_chan_add() before any callbacks are executed. This prevents the scenario where a socket becomes accessible to other threads while still being referenced by an incomplete callback execution. The solution also incorporates inheritance of parent channel configuration properties, which reduces code complexity and potential inconsistencies that could lead to additional vulnerabilities. By centralizing channel initialization logic, the implementation maintains consistency in security posture across different Bluetooth L2CAP connection types while providing robust protection against similar race condition scenarios. This represents a comprehensive fix that not only resolves the immediate vulnerability but also improves the overall architecture of the Bluetooth subsystem's connection handling mechanisms.
The mitigation strategy involves upgrading to kernel versions containing this fix, which typically requires system administrators to update their kernel packages and reboot systems to ensure all processes are running with the patched code. Organizations should prioritize this update, particularly those operating embedded devices or systems where Bluetooth connectivity is critical. The fix demonstrates proper defensive programming practices that align with modern kernel security standards, emphasizing the importance of resource ownership semantics in concurrent systems and preventing temporal gaps that could enable memory corruption attacks.