CVE-2026-80789
NoneCVSS
—
EPSS
0.2%
Published
Sep 4, 2026
CISA due date
—
Cloudanix analysis
A bug in Linux storage networking code lets a remote system reserve huge amounts of memory on a storage server, which can disrupt storage services until the server is updated.
- Exploitation
- Remote Unauthenticated
- Attacker needs
- None
- Complexity
- Low
- Impact
- Denial Of Service
- Component
- OS kernel
- Class
- Improper Input Validation
- Remediation
- Patch
- Effort
- Low
- Patch risk
- Low
What it actually does
Unbounded kernel memory allocation (up to 4 GiB) in nvmet-tcp triggered by host-controlled SGL length fields for non-inline transport descriptors, bypassing checks in nvmet_tcp_map_data before sgl_alloc and before nvmet_check_transfer_len validation.
Why it matters to the business
Remote peers can exhaust kernel memory on NVMe/TCP storage targets, leading to denial of service for storage services; low EPSS and no KEV status indicate limited observed exploitation but the flaw affects Linux kernel deployments handling NVMe over TCP.
How an attack unfolds
An attacker reaches an NVMe/TCP target portal, completes an unauthenticated Fabrics connect, and issues a single crafted write command using a non-inline SGL descriptor with an oversized length; this drives sgl_alloc before any transfer length validation, leaving the allocation resident pending an R2T that is never satisfied.
How to fix it
Apply the upstream kernel fix that enforces NVMET_TCP_MAXH2CDATA validation on every SGL descriptor type inside nvmet_tcp_map_data before any allocation; rebuild and deploy the patched kernel on all affected NVMe/TCP targets.
How to confirm the fix worked
Confirm the bound check exists in nvmet_tcp_map_data for all descriptor types; test by sending a crafted oversized non-inline SGL write command and verify it is rejected before sgl_alloc.
Typical attack path
- Reach the NVMe/TCP target portal and complete a Fabrics connect
- Send a crafted NVMe write command carrying an oversized non-inline SGL length
- Trigger sgl_alloc of up to 4 GiB that remains allocated until command timeout
How to detect it
Inspect kernel logs for nvmet-tcp allocation warnings or large GFP_KERNEL allocations tied to nvmet_req; monitor for repeated Fabrics connects followed by incomplete write commands that leave allocations pending.
What your security team should do
- Prioritize kernel updates containing the nvmet-tcp SGL length bound on all systems exposing NVMe/TCP portals
- Restrict network access to NVMe/TCP target ports to trusted initiators only
- Enable any available authentication mechanisms for NVMe/TCP even if not mandatory by default
The record
In the Linux kernel, the following vulnerability has been resolved: nvmet-tcp: bound SGL data length before allocating command buffers nvmet_tcp_map_data() reads the host-controlled 32-bit sgl->length and, for the in-capsule offset descriptor (type 0x01), checks it against port->inline_data_size before use. Any other SGL descriptor type -- including the non-inline transport SGL data-block descriptor (type (NVME_TRANSPORT_SGL_DATA_DESC << 4) | NVME_SGL_FMT_TRANSPORT_A, the type a real host uses for out-of-capsule writes) skips that check entirely and falls straight through to: cmd->req.sg = sgl_alloc(len, GFP_KERNEL, &cmd->req.sg_cnt); with len taken directly from the wire, unbounded up to 4 GiB. nvmet_req_init() only parses the command and never inspects sgl->length, and nvmet_check_transfer_len() -- the only other place transfer_len is validated -- runs later, from req->execute(), after the allocation has already happened. For a write command the target responds with an R2T and parks the command waiting for the host to send the data; if the host (or an unauthenticated peer that simply never follows up) never does, the sgl_alloc() buffer stays resident for the life of the command. NVMe/TCP has no mandatory authentication in the default configuration, so any peer able to reach the target portal and complete a Fabrics connect can drive this with a single crafted command, repeatable across queues and connections for amplification. This is unbounded kernel memory allocation triggered by a remote, effectively unauthenticated peer. Validate len against the same NVMET_TCP_MAXH2CDATA ceiling this file already uses to bound per-PDU H2C data, for every SGL descriptor type, before doing any allocation. This closes the gap for the non-inline descriptor while leaving the existing, tighter inline_data_size check in place for the in-capsule case. Runtime-verified on a v6.19 KASAN stand: with this bound in place, a crafted write command carrying an oversized non-inline SGL length is rejected before sgl_alloc() runs, where the same request previously drove an unbounded ~256 MiB kernel allocation (up to 4 GiB) that stayed resident pending an R2T the host never satisfies.
Affected packages
| Ecosystem | Package | Introduced | Fixed |
|---|