CVE-2026-53357
Received Received - Intake

Use-After-Free in Linux Kernel Bluetooth L2CAP

Publication date: 2026-07-02

Last updated on: 2026-07-02

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-02
Generated
2026-07-02
AI Q&A
2026-07-02
EPSS Evaluated
N/A
NVD
CVE-2026-53357
EUVD
EUVD-2026-41372

Affected Vendors & Products

Showing 1 associated CPE
Vendor Product Version / Range
linux linux_kernel *

Helpful Resources

Exploitability

CWE
CWE Icon
KEV
KEV Icon
CWE ID Description
CWE-UNKNOWN

Attack-Flow Graph

AI Quick Actions

Instant insights powered by AI
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.

Chat Assistant

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

EPSS Chart