Skip to main content

Linux Kernel CVE-2026-53358

| EUVDEUVD-2026-41373 HIGH
Improper Locking (CWE-667)
2026-07-02 Linux GHSA-g5v6-wm74-gh57
Linux Information Disclosure Red Hat Suse
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
5.3 MEDIUM

Adjacent Bluetooth range (AV:A) and a timing-dependent lock-order race (AC:H); realistic impact is a kernel deadlock/DoS (A:H) with no evidenced confidentiality or integrity primitive (C:N/I:N).

3.1 AV:A/AC:H/PR:N/UI:N/S:U/C:N/I:N/A:H
4.0 AV:A/AC:H/AT:N/PR:N/UI:N/VC:N/VI:N/VA:H/SC:N/SI:N/SA:N
SUSE
5.5 MEDIUM
AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
Red Hat
5.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
Jul 18, 2026 - 08:27 vuln.today
CVSS changed
Jul 18, 2026 - 08:22 NVD
8.8 (HIGH)
Patch available
Jul 02, 2026 - 16:17 EUVD
CVE Published
Jul 02, 2026 - 13:43 cve.org
UNKNOWN (no severity yet)
CVE Published
Jul 02, 2026 - 13:43 cve.org
HIGH 8.8

DescriptionCVE.org

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.

AnalysisAI

A locking-order inversion in the Linux kernel Bluetooth L2CAP subsystem's cleanup_listen() path lets an adjacent attacker trigger a race that can deadlock or corrupt channel state, affecting virtually every Linux distribution shipping the affected kernel with an active Bluetooth stack. cleanup_listen() called l2cap_chan_close() (which manipulates conn->chan_l) under the parent sk_lock, inverting the established conn->lock -> chan->lock -> sk_lock ordering; the fix reschedules channel teardown asynchronously via l2cap_chan_timeout. No public exploit is identified at time of analysis and EPSS exploitation probability is low (0.17%, 6th percentile), so this is a proximity-bound reliability/memory-safety fix rather than a mass-exploitation threat.

Technical ContextAI

The flaw lives in the L2CAP (Logical Link Control and Adaptation Protocol) layer of the Linux Bluetooth (in-kernel BlueZ) stack, in net/bluetooth/l2cap_core.c and its socket teardown paths. L2CAP multiplexes higher-layer Bluetooth protocols over an ACL link and tracks per-connection channels in the conn->chan_l list, guarded by a strict lock hierarchy: conn->lock before chan->lock before the socket-layer sk_lock. cleanup_listen() runs while already holding the parent listening socket's sk_lock, so calling l2cap_chan_close() (which must take conn->lock to unlink the channel from conn->chan_l) inverts that order and creates an AB/BA lock-ordering hazard. CWE is listed as N/A by the source, but the root-cause class is improper locking / lock-order inversion (CWE-667), with a secondary race-condition dimension (CWE-362) because the fix must guard against l2cap_conn_del() concurrently clearing chan->conn. The corrected code schedules l2cap_chan_timeout with zero delay so the existing timeout handler performs the close under the correct conn->lock -> chan->lock order, and only arms the timer when chan->conn is still set to avoid double-teardown.

RemediationAI

Vendor-released patch: update to a fixed stable kernel - 5.10.259, 5.15.210, 6.1.176, 6.6.143, 6.12.93, 7.0.12, or 6.18.35 (or the 7.1 series) - or the equivalent distribution kernel that backports these commits, then reboot to load the new kernel. The upstream commits are available at git.kernel.org (e.g. https://git.kernel.org/stable/c/3634cbdc2eb414b69ffa752ddbe5e0458518e321) and referenced from the NVD advisory https://nvd.nist.gov/vuln/detail/CVE-2026-53358. If you cannot patch immediately, the most effective compensating control is to disable the Bluetooth stack where it is not required - unload the modules with 'modprobe -r btusb bluetooth' or blacklist them and stop/disable bluetoothd; the trade-off is loss of all Bluetooth functionality such as keyboards, audio, and BLE peripherals. Where Bluetooth must stay enabled, reduce exposure by keeping the device non-discoverable/non-connectable and physically limiting who is within radio range, accepting that this only shrinks rather than eliminates the adjacent attack surface. There is no configuration flag that isolates the specific L2CAP cleanup_listen() path, so patching is the only complete fix.

Same weakness CWE-667 – Improper Locking

View all
CVE-2025-43510 HIGH POC
7.8
CVE-2019-5886 CRITICAL POC
9.8
CVE-2020-13246 HIGH POC
7.5
CVE-2019-15513 HIGH POC
7.5
CVE-2019-11599 HIGH POC
7.0
CVE-2023-21400 MEDIUM POC
6.7
CVE-2021-20291 MEDIUM POC
6.5
CVE-2026-53049 CRITICAL
9.8

Same technique Information Disclosure

View all
CVE-2019-2725 CRITICAL POC
9.8
CVE-2021-34523 CRITICAL POC
9.0
CVE-2013-2251 CRITICAL POC
9.8
CVE-2017-5638 CRITICAL POC
9.8
CVE-2025-24813 CRITICAL POC
9.8
CVE-2015-1701 HIGH POC
7.8
CVE-2017-0147 HIGH POC
7.5
CVE-2014-6324 HIGH POC
8.8

Vendor StatusVendor

SUSE

Severity: Moderate
Product Status
Image SLES15-SP7-Azure-3P Image SLES15-SP7-Azure-Basic Image SLES15-SP7-Azure-Standard Image SLES15-SP7-HPC-Azure Affected
Image SLES15-SP7-BYOS-Azure Image SLES15-SP7-BYOS-GCE Image SLES15-SP7-CHOST-BYOS-Aliyun Image SLES15-SP7-CHOST-BYOS-Azure Image SLES15-SP7-CHOST-BYOS-EC2 Image SLES15-SP7-CHOST-BYOS-GCE Image SLES15-SP7-CHOST-BYOS-GDC Image SLES15-SP7-CHOST-BYOS-SAP-CCloud Image SLES15-SP7-EC2 Image SLES15-SP7-EC2-ECS-HVM Image SLES15-SP7-GCE Image SLES15-SP7-HPC-BYOS-Azure Image SLES15-SP7-HPC-BYOS-EC2 Image SLES15-SP7-HPC-BYOS-GCE Image SLES15-SP7-Hardened-BYOS-Azure Image SLES15-SP7-Hardened-BYOS-EC2 Image SLES15-SP7-Hardened-BYOS-GCE Image SLES15-SP7-SAPCAL-Azure Image SLES15-SP7-SAPCAL-EC2 Image SLES15-SP7-SAPCAL-GCE Affected
Image SLES15-SP7-SAP-Azure Image SLES15-SP7-SAP-Azure-3P Image SLES15-SP7-SAP-BYOS-Azure Image SLES15-SP7-SAP-BYOS-EC2 Image SLES15-SP7-SAP-BYOS-GCE Image SLES15-SP7-SAP-EC2 Image SLES15-SP7-SAP-GCE Image SLES15-SP7-SAP-Hardened-Azure Image SLES15-SP7-SAP-Hardened-BYOS-Azure Image SLES15-SP7-SAP-Hardened-BYOS-EC2 Image SLES15-SP7-SAP-Hardened-BYOS-GCE Image SLES15-SP7-SAP-Hardened-GCE Affected
SUSE Linux Enterprise Desktop 15 SP7 Fixed
SUSE Linux Enterprise High Availability Extension 15 SP7 Fixed

Share

CVE-2026-53358 vulnerability details – vuln.today
Back

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