CVE-2026-80789

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.