Skip to main content

Linux Kernel CVE-2026-53071

| EUVDEUVD-2026-38939 HIGH
Missing Lock Check (CWE-414)
2026-06-24 Linux GHSA-g7cw-xhg8-933g
8.8
CVSS 3.1 · Vendor: Linux
Share

Severity by source

Vendor (Linux) PRIMARY
8.8 HIGH
AV:A/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H
vuln.today AI
6.4 MEDIUM

Bluetooth proximity (AV:A) and unauthenticated link (PR:N), but winning the race window raises AC:H; primary impact is kernel panic (A:H) with limited, unproven memory disclosure/corruption (C:L/I:L).

3.1 AV:A/AC:H/PR:N/UI:N/S:U/C:L/I:L/A:H
4.0 AV:A/AC:H/AT:N/PR:N/UI:N/VC:L/VI:L/VA:H/SC:N/SI:N/SA:N
SUSE
7.1 HIGH
AV:A/AC:H/PR:L/UI:N/S:U/C:H/I:H/A:H
Red Hat
7.5 MEDIUM
qualitative

Primary rating from Vendor (Linux).

CVSS VectorVendor: Linux

Attack Vector
Adjacent
Attack Complexity
Low
Privileges Required
None
User Interaction
None
Scope
Unchanged
Confidentiality
High
Integrity
High
Availability
High

Lifecycle Timeline

5
Analysis Generated
Jun 28, 2026 - 09:03 vuln.today
CVSS changed
Jun 28, 2026 - 08:22 NVD
8.8 (HIGH)
Patch available
Jun 24, 2026 - 18:02 EUVD
CVE Published
Jun 24, 2026 - 16:30 cve.org
UNKNOWN (no severity yet)
CVE Published
Jun 24, 2026 - 16:30 cve.org
HIGH 8.8

DescriptionCVE.org

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().

AnalysisAI

Race-condition memory corruption in the Linux kernel Bluetooth L2CAP stack lets a nearby BLE device crash or potentially compromise an affected host. The l2cap_ecred_reconf_rsp() handler calls l2cap_chan_del() without first taking l2cap_chan_lock(), so a crafted L2CAP Enhanced Credit (ECRED) reconfiguration response can mutate the channel list while another kernel thread iterates it. The flaw carries a vendor CVSS of 8.8 but a very low EPSS (0.16%, 6th percentile), is not in CISA KEV, and no public exploit has been identified at time of analysis; a vendor patch is available.

Technical ContextAI

The vulnerability lives in the Bluetooth Low Energy L2CAP implementation (net/bluetooth/l2cap_core.c). L2CAP's Enhanced Credit Based Flow Control (ECRED) mode, introduced for LE connection-oriented channels, processes reconfiguration responses in l2cap_ecred_reconf_rsp(). Channel teardown via l2cap_chan_del() must be serialized by the per-channel mutex l2cap_chan_lock() and protected by a reference via l2cap_chan_hold()/l2cap_chan_put(); every other caller in the file (e.g. l2cap_ecred_conn_rsp() and l2cap_conn_del()) follows this pattern, but the reconf-response path omitted it. The result is a classic concurrency defect - CWE-362 (race condition) leading to CWE-416 (use-after-free) / list corruption - where one thread frees or unlinks a channel object while another walks the list, corrupting kernel memory. The CPE data identifies the affected product generically as cpe:2.3:a:linux:linux:*, i.e. the upstream Linux kernel, with the bug present since the ECRED code was added (around v5.7).

RemediationAI

Vendor-released patch: upgrade to a fixed stable kernel - 5.10.258, 5.15.209, 6.1.175, 6.6.141, 6.12.91, 6.18.33, 7.0.10, or 7.1 (or later in each series), or apply your distribution's backport referencing the kernel.org stable commits (https://git.kernel.org/stable/c/96dca51715d86559ed6ed8028e5445cecb80f3ae and the other listed hashes). The fix simply adds l2cap_chan_hold()/l2cap_chan_lock() before and l2cap_chan_unlock()/l2cap_chan_put() after the l2cap_chan_del() call in l2cap_ecred_reconf_rsp(). Where immediate patching is not possible, the practical compensating control is to remove the attack surface: unload or blacklist the Bluetooth/BLE stack (e.g. disable the bluetooth service and rmmod/blacklist the btusb and bluetooth modules) on systems that do not need it, which fully eliminates exposure at the cost of losing all Bluetooth functionality. On systems that need Bluetooth, keep the radio powered off when unused and avoid pairing/connecting to untrusted LE devices to reduce the window in which a malicious peer can send ECRED reconfiguration responses; this reduces but does not eliminate risk. Track advisories via the NVD entry (https://nvd.nist.gov/vuln/detail/CVE-2026-53071).

Vendor StatusVendor

SUSE

Severity: Important
Product Status
Container suse/sl-micro/6.0/base-os-container:2.1.3-7.168 Container suse/sl-micro/6.1/base-os-container:2.2.1-5.149 Affected
Container suse/sl-micro/6.0/rt-os-container:2.1.3-7.197 Container suse/sl-micro/6.1/rt-os-container:2.2.1-5.145 Affected
Container suse/sle-micro-rancher/5.3:latest Container suse/sle-micro-rancher/5.4:5.4.4.5.149 Affected
Container suse/sle-micro/base-5.5:2.0.4-5.8.296 Affected
Container suse/sle-micro/kvm-5.5:2.0.4-3.5.570 Affected

Share

CVE-2026-53071 vulnerability details – vuln.today

This site uses cookies essential for authentication and security. No tracking or analytics cookies are used. Privacy Policy