CVE-2026-53071

Awaiting Analysis Awaiting Analysis - Queue

Bluetooth: l2cap: Missing chan lock in l2cap_ecred_reconf_rsp

Publication date: 2026-06-24

Last updated on: 2026-07-14

Assigner: kernel.org

Description

In the Linux kernel, the following vulnerability has been resolved: Bluetooth: l2cap: Add missing chan lock in l2cap_ecred_reconf_rsp l2cap_ecred_reconf_rsp() calls l2cap_chan_del() without holding l2cap_chan_lock(). Every other l2cap_chan_del() caller in the file acquires the lock first. A remote BLE device can send a crafted L2CAP ECRED reconfiguration response to corrupt the channel list while another thread is iterating it. Add l2cap_chan_hold() and l2cap_chan_lock() before l2cap_chan_del(), and l2cap_chan_unlock() and l2cap_chan_put() after, matching the pattern used in l2cap_ecred_conn_rsp() and l2cap_conn_del().

CVSS Scores

EPSS Scores

Probability:
Percentile:

Meta Information

Published

2026-06-24

Last Modified

2026-07-14

Generated

2026-07-15

AI Q&A

2026-06-24

EPSS Evaluated

2026-07-13

NVD

CVE-2026-53071

EUVD

EUVD-2026-38939

Affected Vendors & Products

Vendor	Product	Version / Range
linux	linux_kernel	*

Helpful Resources

Exploitability

CWE

KEV

CWE ID	Description
CWE-414	A product does not check to see if a lock is present before performing sensitive operations on a resource.
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 exists in the Linux kernel's Bluetooth L2CAP implementation. Specifically, the function l2cap_ecred_reconf_rsp() calls l2cap_chan_del() without acquiring the necessary channel lock (l2cap_chan_lock()). This is inconsistent with other callers of l2cap_chan_del() that do acquire the lock first.

Because of this missing lock, a remote Bluetooth Low Energy (BLE) device can send a specially crafted L2CAP ECRED reconfiguration response that can corrupt the channel list while another thread is iterating over it. This can lead to data corruption or unexpected behavior in the Bluetooth stack.

The fix involves adding the appropriate locking and reference counting calls (l2cap_chan_hold(), l2cap_chan_lock(), l2cap_chan_unlock(), and l2cap_chan_put()) around l2cap_chan_del() to ensure thread-safe manipulation of the channel list.

Impact Analysis

This vulnerability can allow a remote BLE device to cause corruption in the Bluetooth channel list within the Linux kernel. Such corruption may lead to instability or crashes in the Bluetooth subsystem, potentially causing denial of service or unexpected behavior in Bluetooth communications.

If your system relies on Bluetooth connectivity, especially with BLE devices, this could disrupt normal operations or open the door to further exploitation depending on how the corrupted state is handled.

Mitigation Strategies

The vulnerability has been resolved by adding proper locking mechanisms in the Linux kernel Bluetooth L2CAP code. To mitigate this vulnerability, you should update your Linux kernel to a version that includes this fix.

Specifically, ensure your system is running a kernel version released after 2026-06-24 that contains the patch for the l2cap_ecred_reconf_rsp() function to prevent remote BLE devices from corrupting the channel list.

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

0/70