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_pdu → nvmet_tcp_map_data → sgl_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:
- Linux Kernel Commit 737a3b5
- Linux Kernel Commit 7b6a54d
- Linux Kernel Commit 7fd6da0
- Linux Kernel Commit 86cc450
- Linux Kernel Commit 8d01f0d
- Linux Kernel Commit 9b770e4
- Linux Kernel Commit 9c95f7e
- Linux Kernel Commit c509f20
- Linux Kernel Commit e7077e6
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.
# 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.

