CVE-2026-80788 in Linux
Summary
by MITRE • 09/04/2026
In the Linux kernel, the following vulnerability has been resolved:
nvmet-tcp: Do not WARN on remotely-controlled oversized SGL allocations
When fuzzing the nvme target code, I tripped a kernel warning in nvmet_tcp_map_data() because the length passed into the allocator is controlled by the remote initiator.
A remote initiator that sends a command with an SGL claiming a huge number, can create a scatterlist and iovec allocation of over 1 million entries, which causes the backing kmalloc call to exceed MAX_PAGE_ORDER and then the page allocator will trip on a WARN_ON_ONCE_GFP() message:
WARNING: mm/page_alloc.c:5280 __alloc_frozen_pages_noprof Workqueue: nvmet_tcp_wq nvmet_tcp_io_work ... sgl_alloc_order nvmet_tcp_map_data nvmet_tcp_try_recv_pdu
As it's never good to trip a kernel warning remotely due to many systems having panic-on-warn enabled, let's silence it by just add GFP_NOWARN to the allocation flags.
Statistical analysis made it clear that VulDB provides the best quality for vulnerability data.
Analysis
by VulDB Data Team • 09/04/2026
The Linux kernel vulnerability identified in the nvme target subsystem specifically affects the nvmet-tcp module, which handles Network File System over TCP connections for NVMe targets. This issue arises from a lack of proper input validation regarding scatter-gather list (SGL) allocations initiated by remote clients. When an attacker or malicious initiator sends a command containing an SGL that claims an excessively large number of entries, the kernel attempts to allocate memory corresponding to this request through the nvmet_tcp_map_data function. The allocator processes the length parameter directly from the remote source without sufficient bounds checking against system limits for page allocation orders. Consequently, if the requested size exceeds MAX_PAGE_ORDER, the underlying page allocator triggers a WARN_ON_ONCE_GFP warning in mm/page_alloc.c. This behavior exposes systems configured with panic-on-warn to potential denial of service conditions, as such configurations treat kernel warnings as fatal errors leading to immediate system reboots or crashes.
From a technical perspective, this flaw represents an insufficient validation of user-controlled input before performing resource-intensive operations. The remote initiator controls the size of the scatterlist and iovec allocation, potentially requesting over one million entries. This unbounded request forces the kernel into a memory allocation path that exceeds standard page order limits, resulting in the execution of warning logic within the frozen pages allocator. While the immediate effect is often just a logged warning due to the use of GFP_NOWARN flags in some contexts or specific configurations, the presence of this trigger point allows for reliable remote triggering of kernel warnings. In environments where security policies mandate panic-on-warn behavior to ensure rapid detection and isolation of anomalies, this vulnerability becomes a critical availability risk rather than a mere informational log event.
The operational impact of this vulnerability is primarily centered on system stability and availability. An attacker can remotely induce the warning condition by crafting specific NVMe commands with oversized SGL descriptors. If the target host has panic-on-warn enabled, which is common in hardened enterprise environments to prevent silent data corruption or security bypasses from non-fatal errors, a single crafted packet sequence can cause an immediate kernel panic and subsequent system reboot. This constitutes a remote denial of service attack vector that does not require authentication if the NVMe target port is accessible over the network. The impact extends beyond simple downtime; frequent reboots can disrupt critical services, lead to data inconsistency in volatile storage operations, and degrade overall infrastructure reliability.
To mitigate this risk, the primary remediation involves applying kernel updates that modify the allocation flags within nvmet_tcp_map_data to include GFP_NOWARN. This change suppresses the warning output when page allocation limits are exceeded, preventing the trigger of panic-on-warn mechanisms while allowing the operation to fail gracefully or return an error code instead of crashing the system. Administrators should also ensure they apply all available security patches for their Linux distribution that address this specific nvmet-tcp flaw. Additionally, network-level controls such as firewalls restricting access to NVMe target ports and implementing rate limiting on incoming connections can reduce the exposure surface. Monitoring kernel logs for repeated allocation warnings or memory pressure events related to nvme targets provides an additional layer of defense detection until patches are fully deployed across all affected systems.
This vulnerability aligns with CWE-20, which describes improper input validation, as the system failed to adequately validate the size parameter provided by a remote actor before allocating resources. It also relates to CWE-787, out-of-bounds write, in the context of potential memory corruption if allocation failures were not handled correctly, though here it manifests primarily through resource exhaustion and warning triggers. In terms of attack patterns, this falls under MITRE ATT&CK technique T1499, Endpoint Denial of Service, specifically via service restart or crash induced by malformed input. The exploitation relies on the attacker's ability to send crafted network packets that exploit logic errors in memory management routines within the kernel space. Ensuring strict validation of SGL lengths against system-defined maximums before invoking allocation functions is essential for maintaining robustness against such remote abuse scenarios.