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
Information Disclosure Linux
8.8
CVSS 3.1 · Vendor: Linux
View

Attack ChainAIDerived

Hypothetical attack flow derived from CVE metadata – not a confirmed exploit chain

  1. Access
    Position within Bluetooth range
  2. Delivery
    Open L2CAP connection to listening socket
  3. Exploit
    Rapidly tear down during cleanup_listen
  4. Execution
    Trigger inverted lock-order race
  5. Persist
    Deadlock or corrupt channel state
  6. Impact
    Denial of service on host

Vulnerability Assessment

Weakness
CWE
CWE-667
ASVS 5.0
V15 - Secure Coding and Architecture Proper locking
Exploitation Conditions

Exploitation requires Bluetooth radio proximity (AV:A) to a Linux host whose in-kernel Bluetooth stack is active and has an L2CAP socket in the listening state, since the bug is in cleanup_listen() operating on a parent listening socket. The attacker must drive concurrent connection/teardown activity to win a narrow lock-ordering/teardown race, so despite the vector's AC:L rating the practical condition is a timing-sensitive race that may need many attempts. Limiting factors: the target must have Bluetooth enabled and reachable (not disabled, blocked, or out of range) and must run an unpatched affected kernel; no authentication or pairing is indicated as required per PR:N, but hosts with Bluetooth disabled or modules unloaded are not exploitable at all.
Impact

The signals conflict and warrant caution. The supplied CVSS 3.1 vector (AV:A/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H, base 8.8) implies trivial adjacent unauthenticated exploitation with full confidentiality, integrity, and availability loss, but the description describes a lock-order inversion whose realistic worst case is a deadlock (denial of service) or a teardown race - not a clean read/write primitive - so the C:H/I:H rating appears optimistic and AC:L understates the timing/race precision an attacker actually needs. EPSS is low (0.17%, 6th percentile), there is no KEV listing, and no public exploit exists, consistent with a hard-to-weaponize kernel race rather than a broadly exploited bug. The source Tags label this 'Information Disclosure,' which does not obviously match a locking/deadlock fix and should be treated as an unverified classification - verify with vendor. Net assessment: real but modest priority - patch on the normal stable-kernel cadence; it is not a drop-everything emergency, and the high nominal CVSS is likely automated over-scoring for a Bluetooth-range, race-dependent condition. Missing/conflicting data noted explicitly: CWE is N/A, the impact tag conflicts with the described deadlock/locking nature, and no independent PoC or exploitation evidence exists.
Exploit ScenarioDerived

An attacker within Bluetooth radio range of a vulnerable Linux host repeatedly opens and abruptly tears down L2CAP connections against a listening L2CAP socket, racing the cleanup_listen() path to hit the inverted lock ordering and stall or corrupt kernel channel state, degrading or hanging the target's Bluetooth stack (or worse, if the teardown race is turned into a use-after-free). No public exploit is identified at time of analysis, and success depends on precise timing, so exploitation is opportunistic and unreliable rather than turnkey.
This Week Schedule remediation this week. Why: Active threat signals + CRITICAL/HIGH severity.
Patch available 0.2% exploitation probability (EPSS)

Get an e-mail when this CVE is exploited, patched or re-scored. Free account.

Alert me

AnalysisAIv1 – Jul 18, 2026

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.

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.

Affected VersionsENISA

Linux 3df91ea20e744344100b10ae69a17211fcf5b207 <deb8493a8fa599f6c95e2465b12bfdfb7f94a1d9
Linux 3.4
Linux 3df91ea20e744344100b10ae69a17211fcf5b207 <50dfec218808b148ab4247b1858031b7a32015c5
Linux 3df91ea20e744344100b10ae69a17211fcf5b207 <8c8e620467a7b51562dbcefbd1f09f288d7d710d
Linux patch: 6.12.93
Linux patch: 5.10.259
Linux 3df91ea20e744344100b10ae69a17211fcf5b207 <e1c100e2d61bd8c718b7d91fe3e050780a9bf72d
Linux patch: 7.1
Linux 3df91ea20e744344100b10ae69a17211fcf5b207 <89dec92041717b027216e110599e4f6d6c921b79
Linux 3df91ea20e744344100b10ae69a17211fcf5b207 <859d3ace791ed878ae9ba5522c7844d960da8f88
Linux patch: 6.1.176
Linux patch: 5.15.210
Linux patch: 7.0.12
Linux patch: 0
Linux 3df91ea20e744344100b10ae69a17211fcf5b207 <7555fd885a0603f50e49a655850a1f2bd8a25398
Linux patch: 6.6.143
Linux 3df91ea20e744344100b10ae69a17211fcf5b207 <3634cbdc2eb414b69ffa752ddbe5e0458518e321
Linux patch: 6.18.35

Affected Packages

euvd linux no fix

Source: OSV (Open Source Vulnerabilities)

Affects your stack

Affects 1 package in euvd

Checking this CVE against your own stacks and servers is part of the Basic plan and up.

Sign in to check
Technical ContextAI · show details

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.

Know when the next one hits your stack

  • Watch products and get an email when something new is published
  • Check this CVE against your own stack and servers
  • Exploit and PoC references, threat intelligence from 22 sources
Continue with Google Continue with GitHub

No credit card · 7-day full trial

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

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

4
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.

Executive ViewAI

Why It Matters

A locking defect in Linux kernel Bluetooth subsystems can cause system deadlocks or memory corruption on affected hosts, creating availability risk across organizations running Linux desktops, laptops, and Bluetooth-enabled servers. While active exploitation remains unlikely (0.2% EPSS), the broad distribution of vulnerable code across Linux variants means remediation through patching is required to eliminate crash scenarios.

Business Impact: High
Compensating Controls

Apply vendor patch. If patch deployment extends beyond 7 days, disable Bluetooth on non-critical systems and implement network segmentation to restrict adjacent network access.

Threat Intelligence Overview

EPSS Score
0.2%
Top 94% exploitable
Prevalence
Ubiquitous
Linux kernel with in-tree Bluetooth L2CAP stack, deployed across countless devices
Threat Intel
1
1 source
Data Quality
6 sources
Confidence: High
EUVD NVD CVE.org EPSS CISA Vendor VulDB

How this decision was reached

The engine reads each signal below and applies a fixed list of rules from top to bottom. The first rule that matches sets the recommended action – like a statement, every line is shown.

SignalValue
Severity HIGH
CISA KEV No
Public POC No
EPSS 0.2%
Patch available Yes
Active threat Yes
Deciding rule
Active threat signals + CRITICAL/HIGH severity
What every action level means
Emergency Immediate action required. Criteria: CRITICAL + in CISA KEV (actively exploited) without patch, OR CRITICAL + EPSS > 30% without patch, OR CRITICAL + active threat signals without patch.
Act Now Prioritize within 24-48h. Criteria: in KEV with patch available, OR CRITICAL + public POC, OR HIGH + EPSS > 10%, OR CRITICAL + active threat, OR any CRITICAL severity.
This Week Schedule remediation this week. Criteria: HIGH severity (CVSS 7.0-8.9). Patch within normal change window.
This Month Plan within 30 days. Criteria: MEDIUM severity (CVSS 4.0-6.9), lower exploitation probability. Include in regular patch cycle.
Monitor Track and reassess. Criteria: LOW severity (CVSS 0.1-3.9), minimal exploitation risk. No immediate action needed.

SSVC AssessmentENISA

SSVC Decision· derived
Scheduled
Exploitation· derived
None
System Exposure· derived
Controlled
Automatable· derived
No
Human Impact
High

Priority Score

54
Low Medium High Critical
KEV: 0
EPSS: 0
CVSS: +44
PoC: 0
Weaponized: 0
Threat intel: +10
Gov advisory: 0

Attack Technique

Information Disclosure MEDIUM

Information disclosure occurs when an application unintentionally exposes sensitive data that aids attackers in reconnaissance or directly compromises security.

Same weakness CWE-667 – Improper Locking

View all
CVE-2019-10072 HIGH
7.5
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

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-2025-68613 HIGH POC
8.8
CVE-2015-1701 HIGH POC
7.8
CVE-2017-0147 HIGH POC
7.5

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

Threat IntelligenceMISP

CISA Advisories
ICSA-26-295-16
Sources: CISA (public domain)

References

Advisories & patches
ADVISORY https://nvd.nist.gov/vuln/detail/CVE-2026-53358 ADVISORY https://seclists.org/oss-sec/2026/q3/230 ADVISORY https://ubuntu.com/security/notices/USN-8566-1 ADVISORY https://ubuntu.com/security/notices/USN-8568-1 ADVISORY https://vuldb.com/vuln/375930 ADVISORY https://www.suse.com/support/update/SUSE-SU-2026:3130/ ADVISORY https://www.suse.com/support/update/SUSE-SU-2026:3166/ REF https://cert-portal.siemens.com/productcert/html/ssa-784472.html REF https://git.kernel.org/stable/c/3634cbdc2eb414b69ffa752ddbe5e0458518e321 REF https://git.kernel.org/stable/c/50dfec218808b148ab4247b1858031b7a32015c5 REF https://git.kernel.org/stable/c/7555fd885a0603f50e49a655850a1f2bd8a25398 REF https://git.kernel.org/stable/c/859d3ace791ed878ae9ba5522c7844d960da8f88 REF https://git.kernel.org/stable/c/89dec92041717b027216e110599e4f6d6c921b79 REF https://git.kernel.org/stable/c/8c8e620467a7b51562dbcefbd1f09f288d7d710d REF https://git.kernel.org/stable/c/deb8493a8fa599f6c95e2465b12bfdfb7f94a1d9 REF https://git.kernel.org/stable/c/e1c100e2d61bd8c718b7d91fe3e050780a9bf72d

Search Externally

GitHub PoC Exploit-DB PacketStorm Snyk Rapid7 Nuclei Templates Trickest PoC
Back

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