Skip to main content

Linux Kernel CVE-2026-90092

| EUVDEUVD-2026-81953 HIGH
2026-09-17 Linux GHSA-6f8j-3px9-h4jj
High
Disputed · 8.0 Vendor: Linux
View

Attack ChainAIDerived

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

  1. Access
    Local process opens L2CAP listening socket
  2. Delivery
    Attacker in Bluetooth range initiates inbound L2CAP connect
  3. Exploit
    Parent socket released concurrently (teardown race)
  4. Execution
    New sk added to accept queue after BT_CLOSED
  5. Persist
    Dangling parent reference dereferenced (UAF)
  6. Impact
    Kernel memory corruption / crash

Vulnerability Assessment

Exploitation Conditions

Requires: (1) a kernel built with CONFIG_BT and the Bluetooth L2CAP stack active; (2) a local process that creates and then releases an L2CAP listening socket; (3) an attacker within Bluetooth radio range (AV:A) able to initiate an inbound L2CAP connection to the target PSM; and (4) winning a narrow timing race between l2cap_sock_release()/teardown setting the parent state to BT_CLOSED and l2cap_new_connection adding the new socket to the accept queue. Limiting factors: Bluetooth proximity gating (not remotely reachable over IP), the probabilistic race window (chan->state read without consistent locking), the need for a local process to be actively managing an L2CAP listener, and the niche nature of the L2CAP-listen code path. This is NOT default-configuration remote exploitation.

Impact

This is a legitimate memory-safety flaw (a use-after-free on a dangling parent socket reference) but the risk signals are moderate, not urgent. No EPSS score, no CISA KEV listing, and no public PoC are present in the input, so exploitation status is: no public exploit identified at time of analysis. The vendor CVSS of 8.0 (AV:A/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H) overstates ease of exploitation on one axis: the entire vulnerability is a documented race window ('l2cap_sock_new_connection_cb() may race with parent l2cap_chan teardown, due to chan->state accessed without consistent locking'), which realistically warrants AC:H rather than AC:L - the attacker/local task must win a narrow timing race between l2cap_sock_release() teardown and an incoming l2cap_connect. AV:A is correct because the triggering new connection arrives over the Bluetooth radio, meaning the attacker must be within Bluetooth range (proximity-gated, not internet-facing). Unlike its NULL-deref sibling CVE-2026-90091, this is a true UAF, so the C:H/I:H/A:H impact set is defensible (memory corruption can escalate beyond a crash), though weaponizing a kernel UAF into reliable code execution is non-trivial. The CWE is missing from the record - this is CWE-416 (UAF) layered on CWE-362 (race). Net: a real kernel bug worth patching in the normal cycle, but the Bluetooth-adjacency requirement, race-window timing, local privilege prerequisite, and niche CONFIG_BT + L2CAP-listen path make it far from a mass-exploitation priority.

Exploit ScenarioDerived

A local process on a Bluetooth-enabled Linux host holds an L2CAP listening socket and then closes/releases it while an attacker within Bluetooth range initiates an inbound L2CAP connection to the same PSM. If the incoming connection callback wins the race against parent-socket teardown, the new socket is queued on the now-closed (BT_CLOSED) parent's accept queue, leaving a dangling parent reference that is dereferenced as a use-after-free - corrupting kernel memory. No public exploit code is identified at time of analysis.

This Week Schedule remediation this week. Why: HIGH severity (CVSS 7.0-8.9).
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 – Sep 18, 2026

Use-after-free in the Linux kernel Bluetooth L2CAP stack lets a Bluetooth-adjacent attacker corrupt kernel memory by racing an inbound L2CAP connection against the teardown of a parent listening socket, causing dereference of a dangling bt_sk(sk)->parent pointer. Kernels across the 5.10, 5.15, 6.1, 6.6, 6.12, 6.18 and 7.x stable lines are affected (EUVD lists fixed points at 6.1.188, 6.6.157, 6.12.110, 6.18.52 and 7.2.6), and exploitation requires a local process actively managing an L2CAP listener plus an attacker within Bluetooth radio range; the assessed vector is AV:A/AC:H/PR:L, so this is not default-configuration remote exploitation and hinges on winning a narrow timing window. No public exploit code has been identified at time of analysis, and the flaw is not confirmed actively exploited (CISA KEV), but vendor-released patches are available.

RemediationAI

Vendor-released patch: upgrade to Linux 6.1.188, 6.6.157, 6.12.110, 6.18.52, 7.2.6 or 7.3-rc1 (whichever matches your branch), or apply the corresponding stable commit referenced in the CVE record (bf61a65c6093970e3b50031c4b79ebf3bd411eba, 491e4c60017969b053888029998d2a61f298986a, 2a3a27aaf19bf069720e024ce6fde54e6bf80df9 and 87276dc15b559d32757a43b4415c8445fbae06c4 for the 6.1/6.6/6.12/6.18 backports, with c47339e169bf4a0a4cfabb91351471f67744c2bc and d4bfa78fd67929b62b02013c107973e0c5b7aa9a covering the 5.10/5.15 lines). Until patched, the most effective compensating control is to disable the attack surface entirely: unload or blacklist the Bluetooth stack (rmmod btusb/bluetooth, rfkill block all bluetooth, or boot with the module blacklisted) - the trade-off is total loss of Bluetooth functionality, including input devices and audio. Narrower mitigations: restrict the ability to create L2CAP listening sockets to trusted processes (drop CAP_NET_ADMIN/CAP_NET_RAW or apply SELinux/AppArmor socket restrictions), and avoid long-lived L2CAP listeners so the race window during teardown is rarely exercised - though these only reduce, not eliminate, the race window and may break applications using Bluetooth RFCOMM/L2CAP services. Physical proximity gating (keeping the device out of Bluetooth radio range of untrusted devices) is the remaining fallback where no patch can be applied, but is impractical for most deployments. Vendor advisory references are the kernel.org stable commits and https://nvd.nist.gov/vuln/detail/CVE-2026-90092.

Affected VersionsENISA

Linux 6.1.175 <6.1.188
Linux 85426e97dc72f2088ba6d27e74cd58c3fbd43e31
Linux 5.15.209 <5.16
Linux patch: 6.18.52
Linux 6.18.30 <6.18.52
Linux patch: 7.2.6
Linux 5.10.258 <5.11
Linux patch: 7.3-rc1
Linux 7.0.7 <7.1
Linux 7.1
Linux 2ff1a41a912de8517b4482e946dd951b7d80edbf <d4bfa78fd67929b62b02013c107973e0c5b7aa9a
Linux 6.6.140 <6.6.157
Linux a2dcf1a61d056aef15b63c6eae9441344d624389
Linux 0c17c8832562b2aac288e89cefd0f46074f54bcb <bf61a65c6093970e3b50031c4b79ebf3bd411eba
Linux 6.12.88 <6.12.110
Linux patch: 6.12.110
Linux patch: 6.6.157
Linux c88c185ae0a1067823661b220aeea613df2c127b <2a3a27aaf19bf069720e024ce6fde54e6bf80df9
Linux 5105f3e6b2df619c635b5f6a49fac131a36c7952 <491e4c60017969b053888029998d2a61f298986a
Linux 1810e42ff6716f320c7269d5850eca48b07b7427 <87276dc15b559d32757a43b4415c8445fbae06c4
Linux 1b1c0da227bf63479bac9982fc8d12df9aaea0fb
Linux patch: 6.1.188
Linux patch: 0
Linux 2ff1a41a912de8517b4482e946dd951b7d80edbf <c47339e169bf4a0a4cfabb91351471f67744c2bc

Affected Packages

euvd linux fix: 5.11, 5.16, 6.1.188, 6.6.157, 6.12.110, 6.18.52, 7.1

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.

Technical ContextAI · show details

The flaw lives in the Bluetooth L2CAP socket layer of the Linux kernel, specifically the interaction between l2cap_sock_new_connection_cb() and parent-channel teardown in l2cap_sock_teardown_cb(). When a listening L2CAP socket is released, l2cap_sock_shutdown()/l2cap_chan_close() sets the parent channel state to BT_CLOSED and l2cap_sock_kill() frees the parent, while l2cap_sock_cleanup_listen() drains the accept queue. Because chan->state is read in l2cap_connect()/l2cap_new_connection() without holding the same lock used for the write, an inbound connection can slip through after teardown and have its new sk enqueued onto the now-destroyed parent's accept queue, leaving bt_sk(sk)->parent dangling. The upstream fix adds a defensive check that sk_state == BT_LISTEN after acquiring the socket lock in l2cap_sock_new_connection_cb(), and adds lock_sock() around sk_state writes that were previously unguarded, closing the data race. The EUVD tags label this as information disclosure, but the underlying defect class is memory corruption (use-after-free) reachable over the adjacent-network Bluetooth transport.

Know when Bluetooth gets its next vulnerability

  • 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

No credit card · 7-day full trial

Severity by source

Sources disagree (Low–High)
Vendor (Linux) PRIMARY 8.0 HIGH
AV:A/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H
vuln.today AI 7.1 HIGH

AV:A because triggering connection arrives over Bluetooth; AC:H because the flaw is an explicit teardown race; PR:L for the local L2CAP-listening process; UAF supports C/I/A:H.

3.1 AV:A/AC:H/PR:L/UI:N/S:U/C:H/I:H/A:H
4.0 AV:A/AC:L/AT:P/PR:L/UI:N/VC:H/VI:H/VA:H/SC:N/SI:N/SA:N
SUSE 2.9 LOW
AV:L/AC:H/PR:N/UI:N/S:U/C:N/I:L/A:N
Red Hat 7.0 MEDIUM

vuln.today treats the vendor’s rating as authoritative. A higher third-party CVSS (e.g. CISA-ADP) is shown for transparency but does not drive the headline severity.

CVSS VectorVendor: Linux

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

Lifecycle Timeline

4
CVSS changed
Sep 18, 2026 - 18:22 NVD
8.0 (HIGH)
Patch available
Sep 17, 2026 - 17:19 EUVD
CVE Published
Sep 17, 2026 - 16:06 cve.org
HIGH 8.0
CVE Published
Sep 17, 2026 - 16:06 cve.org
UNKNOWN (no severity yet)

DescriptionCVE.org

In the Linux kernel, the following vulnerability has been resolved:

Bluetooth: L2CAP: reject accept queue add unless BT_LISTEN

New sk should not be added to parent socket accept queue after last l2cap_sock_cleanup_listen() has run in l2cap_sock_teardown_cb() and state set to BT_CLOSED, as that can result to UAF on dereferencing the dangling parent reference.

l2cap_sock_new_connection_cb() may race with parent l2cap_chan teardown, due to chan->state accessed without consistent locking:

[Task 1] [Task 2] l2cap_sock_release(parent) l2cap_connect l2cap_sock_shutdown pchan = l2cap_global_chan_by_psm l2cap_chan_lock(pchan) l2cap_chan_close l2cap_sock_teardown_cb pchan->state = BT_CLOSED l2cap_chan_unlock(pchan) ------> l2cap_chan_lock(pchan) l2cap_new_connection l2cap_sock_new_connection_cb l2cap_chan_lock(pchan) <-------- l2cap_chan_unlock(pchan) l2cap_sock_kill(parent) /* bt_sk(sk)->parent dangling */

Fix by adding check for sk_state == BT_LISTEN after acquiring sk lock in l2cap_sock_new_connection_cb(). Add lock_sock() around sk_state writes where missing, to avoid data races.

Although the data races on pchan->state should be fixed too, this defensive sk_state check probably makes sense in any case.

Executive ViewAI

Why It Matters

Linux systems with Bluetooth enabled and active L2CAP listeners are affected by a high-severity use-after-free vulnerability in the kernel Bluetooth stack (CVE-2026-90092). Successful exploitation requires an attacker within Bluetooth radio range and a local process managing an L2CAP listener, making it a complex but potentially impactful attack that could lead to kernel memory corruption, system crashes, or privilege escalation. No public exploit has been identified at time of analysis, but vendor patches are available and should be prioritized to protect exposed endpoints and servers.

Business Impact: High
Compensating Controls

Apply vendor patch.

Threat Intelligence Overview

EPSS Score
0.2%
Top 89% exploitable
Prevalence
High
Linux Bluetooth stack ships on many laptops/Android/embedded, but L2CAP-listen path is niche
Data Quality
5 sources
Confidence: Medium

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 No
Deciding rule
HIGH severity (CVSS 7.0-8.9)
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

40
Low Medium High Critical
KEV: 0
EPSS: 0
CVSS: +40
PoC: 0
Weaponized: 0
Threat intel: 0
Gov advisory: 0
CVE-2025-65824 HIGH POC
8.8 Dec 10

Unauthenticated Bluetooth Low Energy OTA firmware upgrade in the Meatmeet Pro WiFi & Bluetooth Meat Thermometer firmware

CVE-2025-32879 HIGH POC
8.8 Jun 20

CVE-2025-32879 is a security vulnerability (CVSS 8.8) that allows an attacker. Risk factors: public PoC available.

CVE-2025-10457 HIGH POC
8.1 Sep 19

Zephyr's Bluetooth Low Energy connection-response handler fails to verify that a connection request was actually initiat

CVE-2025-20672 CRITICAL
9.8 Jun 02

Heap OOB write in Android Bluetooth driver via incorrect bounds check.

CVE-2026-55330 CRITICAL
9.8 Oct 06

A use-after-free in the Android Bluetooth stack (bluetooth_ccc.cc, function BluetoothCccHandlerCallbackImpl) lets an att

CVE-2020-10135 MEDIUM POC
5.4 May 19

Legacy pairing and secure-connections pairing authentication in Bluetooth BR/EDR Core Specification v5.2 and earlier may

CVE-2026-19570 HIGH
8.8 Oct 09

Memory corruption in the Zephyr RTOS LE Audio Broadcast Sink (subsys/bluetooth/audio/bap_broadcast_sink.c) lets an attac

CVE-2026-90255 HIGH
8.8 Sep 17

A memory leak combined with a use-after-free in the Linux kernel's Bluetooth HCI connection-setup path can crash the ker

CVE-2026-90256 HIGH
8.8 Sep 17

A race condition in the Linux kernel's Bluetooth L2CAP subsystem allows a use-after-free of the hci_conn::l2cap_data poi

CVE-2026-8374 HIGH
8.5 Oct 09

Bluetooth authentication bypass in SwitchBot Door Lock Series allows an attacker within BLE range to manipulate the lock

CVE-2026-89583 HIGH
8.1 Sep 11

Out-of-bounds read in the Linux kernel Bluetooth subsystem's eir_get_service_data() leaks kernel heap memory into usersp

CVE-2026-118603 HIGH
8.0 Oct 28

A stack-based buffer overflow in the vCard parser of the Alpine iLX-F511 in-dash multimedia receiver (build 7.0.0000) le

Vendor StatusVendor

SUSE

Severity: Low
Product Status
SUSE Linux Enterprise Desktop 15 SP7 Affected
SUSE Linux Enterprise Desktop 15 SP7 Affected
SUSE Linux Enterprise High Availability Extension 15 SP7 Affected
SUSE Linux Enterprise High Availability Extension 15 SP7 Affected
SUSE Linux Enterprise High Availability Extension 16.0 Affected

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