Skip to main content

Linux Kernel EUVDEUVD-2026-49112

| CVE-2026-64534 CRITICAL
2026-07-27 Linux GHSA-6vg3-7hp6-mqc5
9.8
CVSS 3.1 · Vendor: Linux
Share

Severity by source

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

Remote over NVMe/TCP (AV:N) but needs a target configured with data digest and a raced INIT_FAILED-plus-digest path (AC:H), an allowed initiator (PR:L); impact is deadlock/DoS (A:H), not confirmed C/I loss.

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

Primary rating from Vendor (Linux).

CVSS VectorVendor: Linux

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

Lifecycle Timeline

5
Analysis Generated
Jul 30, 2026 - 06:45 vuln.today
CVSS changed
Jul 30, 2026 - 06:37 NVD
9.8 (CRITICAL)
Patch available
Jul 27, 2026 - 09:01 EUVD
CVE Published
Jul 27, 2026 - 06:32 cve.org
UNKNOWN (no severity yet)
CVE Published
Jul 27, 2026 - 06:32 cve.org
CRITICAL 9.8

DescriptionCVE.org

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

nvmet-tcp: check INIT_FAILED before nvmet_req_uninit in digest error path

In nvmet_tcp_try_recv_ddgst(), when a data digest mismatch is detected, nvmet_req_uninit() is called unconditionally. However, if the command arrived via the nvmet_tcp_handle_req_failure() path, nvmet_req_init() had returned false and percpu_ref_tryget_live() was never executed. The unconditional percpu_ref_put() inside nvmet_req_uninit() then causes a refcount underflow, leading to a WARNING in percpu_ref_switch_to_atomic_rcu, a use-after-free diagnostic, and eventually a permanent workqueue deadlock.

Check cmd->flags & NVMET_TCP_F_INIT_FAILED before calling nvmet_req_uninit(), matching the existing pattern in nvmet_tcp_execute_request().

AnalysisAI

Denial of service (and potential use-after-free) in the Linux kernel's NVMe-over-TCP target (nvmet-tcp) subsystem allows a connected NVMe-oF initiator to trigger a refcount underflow via a crafted data-digest mismatch. When a command that previously failed nvmet_req_init() (marked NVMET_TCP_F_INIT_FAILED) hits a data digest error, nvmet_req_uninit() runs an unbalanced percpu_ref_put(), producing a percpu_ref warning, a use-after-free diagnostic, and ultimately a permanent workqueue deadlock that hangs the target. No public exploit identified at time of analysis; EPSS is low at 0.16% (6th percentile), and it is not listed in CISA KEV, so despite the 9.8 NVD score this is realistically a stability/DoS bug confined to hosts acting as NVMe-oF TCP targets with data digest enabled.

Technical ContextAI

The affected component is nvmet-tcp, the Linux kernel's NVMe-over-Fabrics target-side implementation that exports block storage to remote initiators over TCP. NVMe/TCP optionally protects PDU payloads with a data digest (ddgst, a CRC32C checksum); nvmet_tcp_try_recv_ddgst() validates that digest on received data. The root cause is an unbalanced reference-count operation: nvmet_req_init() acquires a live percpu reference via percpu_ref_tryget_live(), but on the nvmet_tcp_handle_req_failure() path it returns false and never takes that reference. The digest-error handler nevertheless called nvmet_req_uninit() unconditionally, whose internal percpu_ref_put() then drives the counter below zero. This is a classic reference-counting/lifetime defect (CWE-911/CWE-416 family; the input lists CWE as N/A) that manifests as a WARNING in percpu_ref_switch_to_atomic_rcu, a use-after-free, and a workqueue deadlock. The fix mirrors the guard already used in nvmet_tcp_execute_request(): check cmd->flags & NVMET_TCP_F_INIT_FAILED before calling nvmet_req_uninit(). CPE data identifies the affected product only generically as cpe:2.3:a:linux:linux, i.e. the mainline kernel, without pinning the storage-target module.

RemediationAI

Vendor-released patch: upgrade to a fixed stable kernel - 5.10.261, 5.15.212, 6.1.178, 6.6.145, 6.12.97, 6.18.40, or mainline 7.1 or later (choose the point release matching your stable series). The upstream fixes are the git.kernel.org stable commits listed in references (e.g. https://git.kernel.org/stable/c/e602c93b25bda4a9d0ff1791a4bdbfdcbb074af1 and the sibling backports 22ec7a9fe915, ba35b1c674ca, c7874dad84b2, d306da8833e7, 2ed3c9d955e8, 4606467a75cf). If you cannot patch immediately and the host does not need to serve NVMe/TCP, the highest-value compensating control is to not load/enable the target: avoid loading the nvmet_tcp module (blacklist it) or tear down the NVMe-oF TCP target configuration, which fully removes the attack surface at the cost of disabling NVMe-oF TCP exports. Where the target must stay online, restrict which initiators can reach the NVMe/TCP port (typically TCP 4420) via firewalling and NVMe-oF host allow-lists so only trusted initiators can submit commands, and consider disabling the data digest (ddgst) option on the target, accepting the loss of payload CRC integrity checking as the trade-off. These controls reduce exposure but do not eliminate the bug, so schedule the kernel upgrade.

Vendor StatusVendor

SUSE

Severity: Critical
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-49112 vulnerability details – vuln.today

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