Skip to main content
CVE Vulnerability Database
Vulnerability Database/CVE-2026-80788

CVE-2026-80788: Linux Kernel nvmet-tcp DoS Vulnerability

CVE-2026-80788 is a denial of service flaw in Linux kernel nvmet-tcp that allows remote attackers to trigger kernel warnings through oversized SGL allocations. This post explains its impact, affected versions, and mitigation steps.

Updated:

CVE-2026-80788 Overview

CVE-2026-80788 affects the Linux kernel's NVMe-over-TCP target subsystem (nvmet-tcp). A remote initiator can send a command with a Scatter-Gather List (SGL) claiming a very large length. The target code passes this attacker-controlled length directly into sgl_alloc_order(), which invokes kmalloc beyond MAX_PAGE_ORDER. The page allocator then triggers a WARN_ON_ONCE_GFP() in __alloc_frozen_pages_noprof. On systems configured with panic_on_warn, this remote-triggered warning results in a kernel panic and denial of service. The fix adds GFP_NOWARN to the allocation flags in nvmet_tcp_map_data() to suppress the warning while allowing the allocation to fail gracefully.

Critical Impact

A remote NVMe-over-TCP initiator can trigger a kernel warning that panics hosts running with panic_on_warn enabled, causing denial of service of the storage target.

Affected Products

  • Linux kernel with nvmet-tcp (NVMe-over-TCP target) enabled
  • Storage systems exposing NVMe-oF targets over TCP
  • Distributions shipping vulnerable stable kernel branches referenced in the upstream commits

Discovery Timeline

  • 2026-09-04 - CVE-2026-80788 published to NVD
  • 2026-09-07 - Last updated in NVD database

Technical Details for CVE-2026-80788

Vulnerability Analysis

The defect resides in nvmet_tcp_map_data() in the Linux kernel's NVMe target TCP transport. When an initiator issues a command carrying an SGL, the target allocates a scatterlist and iovec sized to the SGL's declared length. The declared length is fully controlled by the remote peer.

An initiator that advertises a very large SGL causes the target to request more than one million scatterlist entries. The backing kmalloc call exceeds MAX_PAGE_ORDER, and the page allocator emits WARN_ON_ONCE_GFP() from mm/page_alloc.c. The offending call chain traverses nvmet_tcp_try_recv_pdunvmet_tcp_map_datasgl_alloc_order__alloc_frozen_pages_noprof.

On hosts hardened with panic_on_warn=1, any kernel warning becomes a fatal panic. This turns a benign allocation failure diagnostic into a remotely triggerable denial of service against the storage node.

Root Cause

The root cause is missing sanitization of attacker-controlled allocation sizes combined with the use of allocation flags that surface allocator diagnostics on oversized requests. The nvmet-tcp code trusted the initiator-supplied SGL length and requested memory large enough to trip MAX_PAGE_ORDER checks in the page allocator.

Attack Vector

A remote initiator with network reachability to the NVMe-over-TCP target port sends a crafted PDU containing an SGL descriptor with an oversized length field. No authentication is required beyond whatever the target's discovery and connection controls enforce for NVMe-oF sessions. The oversized SGL triggers the allocation path during PDU processing on the nvmet_tcp_wq workqueue, resulting in a kernel warning and, on hardened kernels, a panic.

See the upstream fixes for the exact code change: Linux Kernel Commit 737a3b5 and Linux Kernel Commit 8d01f0d.

Detection Methods for CVE-2026-80788

Indicators of Compromise

  • Kernel log entries containing WARNING: mm/page_alloc.c with call trace referencing sgl_alloc_order, nvmet_tcp_map_data, and nvmet_tcp_try_recv_pdu.
  • Unexpected panics on NVMe-oF target hosts running with panic_on_warn enabled, correlated with active TCP sessions on the NVMe-oF listener port.
  • NVMe-oF sessions terminating abnormally after receiving a single PDU from an unfamiliar initiator IP.

Detection Strategies

  • Parse dmesg and /var/log/kern.log for the specific warning signature originating from the nvmet_tcp_wq workqueue.
  • Monitor NVMe-oF listener endpoints for connections from unauthorized initiator hosts and for malformed PDUs that fail early in nvmet_tcp_try_recv_pdu.
  • Alert on repeated storage node reboots or workqueue stalls coinciding with NVMe-oF traffic bursts.

Monitoring Recommendations

  • Forward kernel logs from storage targets to a centralized logging or SIEM platform and create rules matching the warning signature.
  • Track connection metadata on NVMe-oF listener ports and baseline expected initiator identities.
  • Instrument host telemetry to capture panic_on_warn reboots with kernel oops context preserved for triage.

How to Mitigate CVE-2026-80788

Immediate Actions Required

  • Apply the upstream kernel patches referenced below to all hosts running nvmet-tcp.
  • Restrict network reachability of NVMe-oF TCP listener ports to trusted initiator subnets using host firewalls and network ACLs.
  • Review panic_on_warn and panic_on_oops sysctl settings on storage targets and weigh the tradeoff between hardening and remote panic exposure until patches are deployed.
  • Inventory kernel versions in use across storage nodes and prioritize patching for internet-adjacent or multi-tenant deployments.

Patch Information

The upstream fix adds GFP_NOWARN to the allocation flags in nvmet_tcp_map_data() so oversized allocations fail without emitting a kernel warning. The change was backported across multiple stable branches:

Workarounds

  • Disable the nvmet-tcp module on hosts that do not require NVMe-over-TCP target functionality.
  • Enforce firewall rules limiting inbound access to the NVMe-oF TCP listener port to a known set of initiator addresses.
  • Temporarily set panic_on_warn=0 on affected storage targets to prevent remote-triggered panics until the patch is applied.
  • Segment storage networks so NVMe-oF targets are unreachable from untrusted networks or tenant workloads.
bash
# Configuration example: constrain nvmet-tcp exposure until patched

# 1. Confirm whether nvmet-tcp is loaded
lsmod | grep nvmet_tcp

# 2. Unload if not in use
modprobe -r nvmet_tcp

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

# 4. Temporarily disable panic_on_warn while planning patch rollout
sysctl -w kernel.panic_on_warn=0

Disclaimer: This content was generated using AI. While we strive for accuracy, please verify critical information with official sources.

Default Legacy - Prefooter | Experience the World’s Most Advanced Cybersecurity Platform

Experience the Most Advanced Cybersecurity Platform

See how the world’s most intelligent, autonomous cybersecurity platform can protect your organization today and into the future.