CVE-2026-53357

Awaiting Analysis Awaiting Analysis - Queue

Use-After-Free in Linux Kernel Bluetooth L2CAP

Publication date: 2026-07-02

Last updated on: 2026-07-22

Assigner: kernel.org

Description

In the Linux kernel, the following vulnerability has been resolved: Bluetooth: fix UAF in l2cap_sock_cleanup_listen() vs l2cap_conn_del() bt_accept_dequeue() unlinks a not-yet-accepted child from the parent accept queue and release_sock()s it before returning, so the returned sk has no caller reference and is unlocked. l2cap_sock_cleanup_listen() walks these children on listening-socket close. A concurrent HCI disconnect drives hci_rx_work -> l2cap_conn_del() which runs l2cap_chan_del() + l2cap_sock_kill() and frees the child sk and its l2cap_chan; cleanup_listen() then uses both: BUG: KASAN: slab-use-after-free in l2cap_sock_kill l2cap_sock_kill / l2cap_sock_cleanup_listen / __x64_sys_close Freed by: l2cap_conn_del -> l2cap_sock_close_cb -> l2cap_sock_kill This is distinct from the two fixes already in this area: commit e83f5e24da741 ("Bluetooth: serialize accept_q access") serialises the accept_q list/poll and takes temporary refs inside bt_accept_dequeue(), and CVE-2025-39860 serialises the userspace close()/accept() race by calling cleanup_listen() under lock_sock() in l2cap_sock_release(). Neither covers l2cap_conn_del() running from hci_rx_work, so this UAF still reproduces on current bluetooth/master. Take the reference at the source: bt_accept_dequeue() does sock_hold() while sk is still locked, before release_sock(); callers sock_put(). cleanup_listen() pins the chan with l2cap_chan_hold_unless_zero() under a brief child sk lock (serialising vs l2cap_sock_teardown_cb()), drops it before l2cap_chan_lock(), and skips a duplicate l2cap_sock_kill() on SOCK_DEAD. conn->lock is not taken here: cleanup_listen() runs under the parent sk lock and that would invert conn->lock -> chan->lock -> sk_lock (lockdep). KASAN/SMP: an unprivileged listen/close vs HCI-disconnect race produced 12 use-after-free reports per run before this change; 0, and no lockdep report, over 1600+ raced iterations after it on bluetooth/master.

CVSS Scores

EPSS Scores

Probability:
Percentile:

Meta Information

Published

2026-07-02

Last Modified

2026-07-22

Generated

2026-07-22

AI Q&A

2026-07-02

EPSS Evaluated

2026-07-21

NVD

CVE-2026-53357

EUVD

EUVD-2026-41372

Affected Vendors & Products

Vendor	Product	Version / Range
linux	linux_kernel	7.1
linux	linux_kernel	7.1
linux	linux_kernel	7.1
linux	linux_kernel	7.1
linux	linux_kernel	From 5.16 (inc) to 6.1.175 (exc)
linux	linux_kernel	From 6.7 (inc) to 6.12.92 (exc)
linux	linux_kernel	From 6.13 (inc) to 6.18.34 (exc)
linux	linux_kernel	From 6.19 (inc) to 7.0.11 (exc)
linux	linux_kernel	From 6.2 (inc) to 6.6.142 (exc)
linux	linux_kernel	From 5.11 (inc) to 5.15.210 (exc)
linux	linux_kernel	From 5.7 (inc) to 5.10.259 (exc)

Helpful Resources

Exploitability

CWE

KEV

CWE ID	Description
CWE-416	The product reuses or references memory after it has been freed. At some point afterward, the memory may be allocated again and saved in another pointer, while the original pointer references a location somewhere within the new allocation. Any operations using the original pointer are no longer valid because the memory "belongs" to the code that operates on the new pointer.

Attack-Flow Graph

Executive Summary

This vulnerability is a use-after-free (UAF) issue in the Linux kernel's Bluetooth subsystem, specifically involving the l2cap_sock_cleanup_listen() function and related Bluetooth socket handling code.

The problem occurs when a child socket that has not yet been accepted is unlinked from the parent's accept queue and freed prematurely by concurrent operations involving HCI disconnect events. This leads to the cleanup function accessing memory that has already been freed, causing a use-after-free bug.

The vulnerability arises due to a race condition between socket acceptance and Bluetooth connection teardown, which was not fully addressed by previous fixes. This can trigger kernel bugs detected by KASAN (Kernel Address Sanitizer) and potentially cause system instability or crashes.

Impact Analysis

This vulnerability can lead to kernel memory corruption due to use-after-free conditions in the Bluetooth subsystem.

Exploitation of this flaw could cause system crashes, instability, or potentially allow an attacker to execute arbitrary code within the kernel context, depending on the attacker's capabilities and environment.

Since it involves Bluetooth socket handling, systems using Bluetooth heavily or exposed to untrusted Bluetooth devices might be at higher risk.

Hi! I’m here to help you understand CVE-2026-53357. Ask me anything about the vulnerability, its impact, or mitigation strategies.

0/70