CVE-2026-53358

Awaiting Analysis Awaiting Analysis - Queue

Bluetooth Use-After-Free in Linux Kernel

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: L2CAP: use chan timer to close channels in cleanup_listen() l2cap_chan_close() removes the channel from conn->chan_l, which must be done under conn->lock. cleanup_listen() runs under the parent sk_lock, so acquiring conn->lock would invert the established conn->lock -> chan->lock -> sk_lock order. Instead of calling l2cap_chan_close() directly, schedule l2cap_chan_timeout with delay 0 to close the channel asynchronously. The timeout handler already acquires conn->lock and chan->lock in the correct order. The timer is only armed when chan->conn is still set: if it is already NULL, l2cap_conn_del() has already processed this channel (l2cap_chan_del + l2cap_sock_teardown_cb + l2cap_sock_close_cb), so there is nothing left to do. If l2cap_conn_del() races in after the timer is armed, __clear_chan_timer() inside l2cap_chan_del() cancels it; if the timer has already fired, the handler returns harmlessly because chan->conn was cleared.

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-53358

EUVD

EUVD-2026-41373

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.176 (exc)
linux	linux_kernel	From 6.13 (inc) to 6.18.35 (exc)
linux	linux_kernel	From 6.2 (inc) to 6.6.143 (exc)
linux	linux_kernel	From 6.7 (inc) to 6.12.93 (exc)
linux	linux_kernel	From 5.11 (inc) to 5.15.210 (exc)
linux	linux_kernel	7.1
linux	linux_kernel	From 6.19 (inc) to 7.0.12 (exc)
linux	linux_kernel	From 3.4 (inc) to 5.10.259 (exc)

Helpful Resources

Exploitability

CWE

KEV

CWE ID	Description
CWE-667	The product does not properly acquire or release a lock on a resource, leading to unexpected resource state changes and behaviors.

Attack-Flow Graph

Executive Summary

This vulnerability relates to the Linux kernel's Bluetooth L2CAP implementation. Specifically, it involves improper handling of channel closure in the cleanup_listen() function. The function l2cap_chan_close() removes a channel from a connection's channel list and must be called while holding a specific lock (conn->lock). However, cleanup_listen() runs under a different lock (sk_lock), and acquiring conn->lock there would invert the required lock acquisition order, potentially causing issues.

To fix this, instead of calling l2cap_chan_close() directly, the kernel schedules a timeout handler (l2cap_chan_timeout) with zero delay to close the channel asynchronously. This timeout handler acquires the necessary locks in the correct order, preventing lock inversion problems and ensuring safe channel closure.

Impact Analysis

This vulnerability could lead to improper synchronization and locking issues within the Bluetooth L2CAP channel closure process in the Linux kernel. Such issues might cause system instability, crashes, or unexpected behavior in Bluetooth communications.

While the description does not explicitly mention security impacts like privilege escalation or data leakage, improper lock handling can potentially be exploited to cause denial of service or other reliability problems affecting systems using Bluetooth.

Mitigation Strategies

The vulnerability has been resolved in the Linux kernel by changing the way Bluetooth L2CAP channels are closed, specifically by scheduling the channel close asynchronously using a timer to avoid lock order inversion issues.

To mitigate this vulnerability immediately, you should update your Linux kernel to a version that includes this fix.

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

0/70