Skip to main content

Linux Kernel EUVDEUVD-2026-45749

| CVE-2026-63976 HIGH
2026-07-19 Linux GHSA-2c97-7qvf-wx4v
Information Disclosure Linux
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.5 MEDIUM

Adjacent Bluetooth vector (AV:A), low complexity, no OS credentials (PR:N); described impact is forced channel teardown so A:H with C:N/I:N - vendor's C:H/I:H likely reflects the latent use-after-free, not the replay itself.

3.1 AV:A/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H
4.0 AV:A/AC:L/AT:N/PR:N/UI:N/VC:N/VI:N/VA:H/SC:N/SI:N/SA:N
SUSE
HIGH
qualitative
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 20, 2026 - 16:37 vuln.today
CVSS changed
Jul 20, 2026 - 15:22 NVD
8.8 (HIGH)
Patch available
Jul 19, 2026 - 17:19 EUVD
CVE Published
Jul 19, 2026 - 14:56 cve.org
HIGH 8.8
CVE Published
Jul 19, 2026 - 14:56 cve.org
UNKNOWN (no severity yet)

DescriptionCVE.org

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

Bluetooth: l2cap: clear chan->ident on ECRED reconfiguration success

l2cap_ecred_reconf_rsp() returns early on success without clearing chan->ident. Every other L2CAP response handler (l2cap_ecred_conn_rsp, l2cap_le_connect_rsp, l2cap_config_rsp) clears chan->ident after a successful transaction to prevent the channel from matching subsequent responses with the recycled ident value.

A remote attacker that completed a reconfiguration as the peer can replay a failure response with the stale ident, causing the kernel to match and destroy the already-established channel via l2cap_chan_del(chan, ECONNRESET).

Clear chan->ident for all matching channels on success, and harden the failure path by using l2cap_chan_hold_unless_zero() consistent with other L2CAP handlers (l2cap_le_command_rej, __l2cap_get_chan_by_ident).

AnalysisAI

Improper channel-identifier handling in the Linux kernel Bluetooth L2CAP stack lets an in-range peer forcibly tear down an established Enhanced Credit (ECRED) connection. Because l2cap_ecred_reconf_rsp() returns on success without clearing chan->ident, a remote peer that completed a reconfiguration can replay a failure response carrying the stale ident, causing the kernel to match and destroy the live channel with l2cap_chan_del(chan, ECONNRESET); the fix also hardens the failure path against a use-after-free. No public exploit is identified at time of analysis and EPSS risk is low (0.31%).

Technical ContextAI

The flaw lives in the L2CAP (Logical Link Control and Adaptation Protocol) layer of the Linux Bluetooth subsystem (net/bluetooth/l2cap_core.c), specifically the Enhanced Credit Based (ECRED) flow used for LE connection-oriented channels. L2CAP tracks in-flight command/response pairs by a per-channel 'ident' value; every other response handler (l2cap_ecred_conn_rsp, l2cap_le_connect_rsp, l2cap_config_rsp) zeroes chan->ident after a successful transaction so a channel cannot be matched again against a recycled ident. l2cap_ecred_reconf_rsp() skipped this clear, leaving a stale ident that a later spoofed/replayed response can match - a state-management / stale-reference defect (no CWE was assigned in the feed, but this maps to CWE-459/CWE-667-style improper cleanup, with the added l2cap_chan_hold_unless_zero() hardening indicating a CWE-416 use-after-free exposure on the failure path). Affected CPE is cpe:2.3:a:linux:linux, i.e., the mainline Linux kernel, with the bug introduced around v5.7.

RemediationAI

Vendor-released patch: upgrade to a fixed stable release for your branch - 5.10.259, 5.15.210, 6.1.176, 6.6.143, 6.12.93, 6.18.35, 7.0.12, or 7.1 - or apply the corresponding backport commit from git.kernel.org (e.g., https://git.kernel.org/stable/c/59f5ecf6ad5c4db6ae81965a96156954a3b0d89a). Because the attack surface is the Bluetooth L2CAP path, a strong compensating control until you can reboot into a patched kernel is to disable the Bluetooth stack where it is not needed - unload the modules (rmmod bluetooth or blacklist bluetooth/btusb) or power the radio down (rfkill block bluetooth); the trade-off is loss of all Bluetooth functionality (keyboards, audio, LE peripherals). Where Bluetooth is required, reduce exposure by keeping devices non-discoverable and only pairing with trusted peers, which limits but does not eliminate the risk since the trigger comes from an already-connected peer. Track the advisory at https://nvd.nist.gov/vuln/detail/CVE-2026-63976.

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: Important
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

Share

EUVD-2026-45749 vulnerability details – vuln.today
Back

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