Skip to main content

Linux Kernel nvme-tcp CVE-2026-89480

| EUVDEUVD-2026-76386 HIGH
2026-09-11 Linux GHSA-p53f-q495-p25h
7.5
CVSS 3.1 · Vendor: Linux
Share

Severity by source

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

Attacker must control the NVMe-TCP storage target the victim connects to, raising AC to H; no victim-system privileges needed; confidentiality impact is high, no integrity or availability effect.

3.1 AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:N/A:N
4.0 AV:N/AC:H/AT:N/PR:N/UI:N/VC:H/VI:N/VA:N/SC:N/SI:N/SA:N

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
None
Availability
None

Lifecycle Timeline

5
Analysis Generated
Sep 13, 2026 - 08:07 vuln.today
CVSS changed
Sep 13, 2026 - 07:22 NVD
7.5 (HIGH)
Patch available
Sep 11, 2026 - 21:18 EUVD
CVE Published
Sep 11, 2026 - 19:43 cve.org
HIGH 7.5
CVE Published
Sep 11, 2026 - 19:43 cve.org
UNKNOWN (no severity yet)

DescriptionCVE.org

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

nvme-tcp: reject a read that transferred too few bytes

nvme_tcp_recv_data() completes a request once the current C2HData PDU has been consumed. Nothing compares the total bytes received against the length the command asked for: struct nvme_tcp_request has no receive-side counter, queue->data_remaining is per queue, and blk_mq_end_request() completes for blk_rq_bytes(rq) unconditionally with no residual concept anywhere above.

A controller can therefore answer a 4096-byte read with 512 bytes and have it reported as a complete read; user space then gets 4096 bytes of which 3584 are whatever was already in the page. I reproduced that with a test target.

Count the bytes received and refuse to complete a successful read whose count does not match, at the two NVME_TCP_F_DATA_SUCCESS paths and in nvme_tcp_process_nvme_cqe(). The success test shifts req->status right by one, because the driver keeps the wire value there and shifts it on completion, so the check must see what the completion path will see. Only REQ_OP_READ is checked, because there the length comes from the sectors the request covers; a passthrough command is built by its submitter, which picks both command and buffer, so the kernel has nothing to compare against.

AnalysisAI

Information disclosure in the Linux kernel's NVMe-over-TCP (nvme-tcp) transport driver allows a malicious or compromised NVMe-TCP storage controller to serve a truncated read response - for example, answering a 4 096-byte read with only 512 bytes while asserting DATA_SUCCESS - causing the kernel to complete the request without detecting the shortfall and deliver a buffer whose unfilled portion contains stale kernel page contents to userspace. Affected kernels include all releases from the introduction of nvme-tcp support (commit 3f2304f8c6d6ed97849057bd16fee99e434ca796) through Linux 6.12.108, 6.18.49, and 7.2.3. …

Unlock full vulnerability intelligence

  • Risk assessment & exploitation conditions
  • Attack chain visualization
  • Remediation with exact patch versions
  • Threat intelligence from 22 sources
  • Personal watchlist & email alerts

Free forever · No credit card required

Attack ChainAIDerived

Hypothetical attack flow derived from CVE metadata

Access
technique details hidden
Delivery
technique details hidden
Exploit
technique details hidden
Execution
technique details hidden
Persist
technique details hidden
Impact
technique details hidden

Vulnerability AssessmentAI

Exploitation Exploitation requires three concurrent conditions: (1) the victim host must have the nvme-tcp kernel module loaded and an active NVMe-over-TCP connection established to a storage target - hosts using NVMe-PCIe, NVMe-RDMA, or no NVMe at all are unaffected; (2) the attacker must control the NVMe-TCP controller (target) side of that connection, either by directly operating a malicious target or by compromising a legitimate storage appliance or by intercepting unencrypted NVMe-TCP traffic; (3) only REQ_OP_READ operations are vulnerable - write commands and NVMe passthrough commands (where the submitter controls both command and buffer) are explicitly excluded by the fix. … Additional conditions and limiting factors are described in the full assessment.
Risk Assessment The CVSS 3.1 vector AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:N yields a base score of 7.5, but this overstates practical risk: exploiting the flaw requires the attacker to control or compromise the NVMe-TCP storage target to which the victim kernel is connected, which is a non-trivial prerequisite that AC:L does not capture. … Full risk analysis with EPSS, KEV, and SSVC signal comparison available after sign-in.
Exploit Scenario Full exploit scenario with step-by-step reproduction available after sign-in.
Remediation Upgrade to Linux 6.12.109, 6.18.50, 7.2.4, or any later release in each series; the 7.3-rc1 development branch also incorporates the fix. … Detailed patch versions, workarounds, and compensating controls in full report.

Recommended ActionAI

Within 24 hours, identify all Linux systems using NVMe-TCP transport and verify which run affected kernel versions (6.12.108 or earlier, 6.18.49 or earlier, or 7.2.3 or earlier in their respective branches). …

Sign in for detailed remediation steps and compensating controls.

Threat intelligence, references, and detailed analysis are available after sign-in.

Share

CVE-2026-89480 vulnerability details – vuln.today

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