CVE-2026-80789: Linux Kernel NVMe/TCP DoS Vulnerability

CVE-2026-80789 Overview

CVE-2026-80789 is a Linux kernel vulnerability in the NVMe over TCP target driver (nvmet-tcp). The flaw resides in nvmet_tcp_map_data(), which reads a host-controlled 32-bit sgl->length field and only validates it for the in-capsule inline descriptor type (0x01). All other Scatter/Gather List (SGL) descriptor types, including the non-inline transport data-block descriptor used for out-of-capsule writes, bypass the size check. An unauthenticated remote peer able to reach the NVMe/TCP target portal can trigger unbounded kernel memory allocations up to 4 GiB per crafted command.

Critical Impact
Remote, unauthenticated peers can drive unbounded kernel memory allocation on NVMe/TCP targets, exhausting system memory and causing denial of service.

Affected Products

Linux kernel nvmet-tcp (NVMe over Fabrics TCP target) module
Systems exposing NVMe/TCP target portals in the default configuration without mandatory Fabrics authentication
Multiple stable kernel branches receiving backports across the nine listed fix commits

Discovery Timeline

2026-09-04 - CVE-2026-80789 published to the National Vulnerability Database
2026-09-04 - Last updated in NVD database

Technical Details for CVE-2026-80789

Vulnerability Analysis

The vulnerability is a resource exhaustion flaw in the kernel's NVMe over Fabrics TCP target implementation. When nvmet_tcp_map_data() processes an incoming command, it inspects the SGL descriptor type. For descriptor type 0x01 (in-capsule inline data), the code correctly checks sgl->length against port->inline_data_size. For any other type, including (NVME_TRANSPORT_SGL_DATA_DESC << 4) | NVME_SGL_FMT_TRANSPORT_A, the check is skipped entirely.

Execution then falls through to cmd->req.sg = sgl_alloc(len, GFP_KERNEL, &cmd->req.sg_cnt) with len sourced directly from the wire. Because the field is a full 32-bit value, a single crafted command can request up to 4 GiB of kernel memory. nvmet_req_init() never inspects sgl->length, and nvmet_check_transfer_len() runs later from req->execute(), after the allocation has already occurred.

For write commands, the target issues a Ready-to-Transfer (R2T) and parks the command awaiting host data. If the peer never follows up, the sgl_alloc() buffer remains resident for the lifetime of the command. Runtime testing on a v6.19 KASAN build confirmed a single request driving roughly 256 MiB of unbounded allocation.

Root Cause

The root cause is missing input validation on an attacker-controlled length field before a kernel memory allocation. The existing bounds check was implemented only for the inline descriptor path, leaving the non-inline transport descriptor path completely unvalidated prior to sgl_alloc().

Attack Vector

NVMe/TCP has no mandatory authentication in its default configuration. Any peer capable of reaching the target portal and completing a Fabrics connect can submit crafted write commands carrying oversized non-inline SGL lengths. Attackers can repeat the pattern across multiple queues and connections for amplification, driving cumulative kernel memory pressure and denial of service against the target host.

No verified public exploit code is available. Detailed technical context is available in the upstream fix commits, including Kernel Git Commit 0952541b and Kernel Git Commit 25ad03d5.

Detection Methods for CVE-2026-80789

Indicators of Compromise

Sustained growth in kernel slab and sgl_alloc allocations correlated with NVMe/TCP target activity
Large numbers of outstanding NVMe/TCP write commands in the R2T state that never receive corresponding H2C data PDUs
Repeated Fabrics connect requests from unexpected peers followed by malformed or oversized SGL descriptors

Detection Strategies

Monitor kernel memory pressure metrics (/proc/meminfo, slabtop) on hosts running nvmet-tcp targets for anomalous growth tied to inbound TCP sessions
Enable NVMe target tracing (/sys/kernel/debug/tracing/events/nvmet) to capture command lengths and descriptor types for offline analysis
Alert on connections to NVMe/TCP portal ports (default 4420/tcp) from source addresses outside the expected storage fabric

Monitoring Recommendations

Baseline typical SGL length distributions per initiator and flag statistical outliers approaching the 4 GiB ceiling
Correlate kernel Out of memory and OOM-killer events with NVMe/TCP target activity in centralized logging
Track long-lived pending write commands as an early signal of the R2T-waiting exhaustion pattern described in the advisory

How to Mitigate CVE-2026-80789

Immediate Actions Required

Apply the upstream kernel patches referenced in the fix commits to all hosts running nvmet-tcp targets
Restrict network reachability of NVMe/TCP portal ports to trusted initiators only using firewall rules or a dedicated storage VLAN
Enable NVMe-oF in-band authentication (DH-HMAC-CHAP) where supported to prevent unauthenticated peers from completing Fabrics connect

Patch Information

The fix validates len against the existing NVMET_TCP_MAXH2CDATA ceiling for every SGL descriptor type before any allocation occurs. This closes the gap for the non-inline descriptor while preserving the tighter inline_data_size check for the in-capsule case. Backports are available across multiple stable branches through the nine referenced commits, including Kernel Git Commit d895e666, Kernel Git Commit f6e51b09, and Kernel Git Commit 14dbe376.

Workarounds

Unload the nvmet-tcp module on hosts that do not require NVMe over Fabrics TCP service until the patch is applied
Place NVMe/TCP target portals behind IPsec or a private management network so only authenticated initiators can reach them
Lower port->inline_data_size and enforce initiator allow-lists where the target framework supports them to reduce blast radius

bash

# Restrict NVMe/TCP target port (default 4420/tcp) to trusted initiators
iptables -A INPUT -p tcp --dport 4420 -s 10.0.10.0/24 -j ACCEPT
iptables -A INPUT -p tcp --dport 4420 -j DROP

# Unload nvmet-tcp if the service is not required
modprobe -r nvmet-tcp