Cloudanix VulnDB

CVE-2026-80788

None

CVSS

—

EPSS

0.2%

Published

Sep 4, 2026

CISA due date

—

Cloudanix analysis

Schedule a fix SSVC: Track

A remote attacker can send a specially crafted storage command that makes certain Linux systems log a scary warning or crash if they are set to panic on warnings.

Exploitation
Remote Unauthenticated
Attacker needs
None
Complexity
Low
Impact
Denial Of Service
Component
OS kernel
Class
Denial of service
Remediation
Patch
Effort
Low
Patch risk
Low

What it actually does

Remote initiator can force nvmet_tcp_map_data to allocate scatterlist and iovec structures exceeding MAX_PAGE_ORDER via a single command with an oversized SGL, triggering a WARN_ON_ONCE_GFP in the page allocator.

Why it matters to the business

Linux NVMe-TCP target systems may experience kernel warnings that become crashes on panic-on-warn configurations, leading to unplanned downtime for storage services.

How an attack unfolds

An attacker connects to an nvmet-tcp target and sends a single NVMe command PDU containing an SGL descriptor that claims more than one million entries; nvmet_tcp_try_recv_pdu calls nvmet_tcp_map_data which performs an unbounded sgl_alloc_order, exceeding the page allocator limit and emitting the warning from the nvmet_tcp_wq workqueue.

How to fix it

Update the Linux kernel to a version containing the fix that adds GFP_NOWARN to the allocation flags in nvmet_tcp_map_data; rebuild and reboot affected systems.

How to confirm the fix worked

Confirm the nvmet-tcp code path contains GFP_NOWARN on sgl_alloc_order calls and that the specific WARNING string from mm/page_alloc.c no longer appears under large SGL fuzzing.

Typical attack path

  1. Establish TCP connection to nvmet target
  2. Send NVMe command PDU with maliciously large SGL length
  3. Trigger nvmet_tcp_map_data allocation path
  4. Observe kernel warning or system panic

How to detect it

Search kernel logs and dmesg for the string 'WARNING: mm/page_alloc.c' combined with 'nvmet_tcp_wq' and 'sgl_alloc_order'; inspect workqueue traces pointing to nvmet_tcp_io_work.

  • 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

What your security team should do

  • Prioritize kernel upgrades on all systems exposing nvmet-tcp targets
  • Disable panic-on-warn if immediate patching is delayed
  • Monitor kernel logs for the page_alloc warning signature
  • Restrict nvmet-tcp exposure to trusted initiators only

The record

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.

Affected packages

Ecosystem Package Introduced Fixed