GHSA-JX2C-6H88-85VX
Vulnerability from github – Published: 2026-09-04 18:31 – Updated: 2026-09-04 18:31In 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": [],
"aliases": [
"CVE-2026-80789"
],
"database_specific": {
"cwe_ids": [],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-09-04T16:18:05Z",
"severity": null
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\nnvmet-tcp: bound SGL data length before allocating command buffers\n\nnvmet_tcp_map_data() reads the host-controlled 32-bit sgl-\u003elength\nand, for the in-capsule offset descriptor (type 0x01), checks it\nagainst port-\u003einline_data_size before use. Any other SGL descriptor\ntype -- including the non-inline transport SGL data-block descriptor\n(type (NVME_TRANSPORT_SGL_DATA_DESC \u003c\u003c 4) | NVME_SGL_FMT_TRANSPORT_A,\nthe type a real host uses for out-of-capsule writes) skips that check\nentirely and falls straight through to:\n\n\tcmd-\u003ereq.sg = sgl_alloc(len, GFP_KERNEL, \u0026cmd-\u003ereq.sg_cnt);\n\nwith len taken directly from the wire, unbounded up to 4 GiB.\n\nnvmet_req_init() only parses the command and never inspects\nsgl-\u003elength, and nvmet_check_transfer_len() -- the only other place\ntransfer_len is validated -- runs later, from req-\u003eexecute(), after\nthe allocation has already happened. For a write command the target\nresponds with an R2T and parks the command waiting for the host to\nsend the data; if the host (or an unauthenticated peer that simply\nnever follows up) never does, the sgl_alloc() buffer stays resident\nfor the life of the command. NVMe/TCP has no mandatory authentication\nin the default configuration, so any peer able to reach the target\nportal and complete a Fabrics connect can drive this with a single\ncrafted command, repeatable across queues and connections for\namplification. This is unbounded kernel memory allocation\ntriggered by a remote, effectively unauthenticated peer.\n\nValidate len against the same NVMET_TCP_MAXH2CDATA ceiling this file\nalready uses to bound per-PDU H2C data, for every SGL descriptor type,\nbefore doing any allocation. This closes the gap for the non-inline\ndescriptor while leaving the existing, tighter inline_data_size check\nin place for the in-capsule case.\n\nRuntime-verified on a v6.19 KASAN stand: with this bound in place, a\ncrafted write command carrying an oversized non-inline SGL length is\nrejected before sgl_alloc() runs, where the same request previously\ndrove an unbounded ~256 MiB kernel allocation (up to 4 GiB) that\nstayed resident pending an R2T the host never satisfies.",
"id": "GHSA-jx2c-6h88-85vx",
"modified": "2026-09-04T18:31:26Z",
"published": "2026-09-04T18:31:26Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-80789"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/0952541b153e258b99d39cdb03ea6919fdeb41d0"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/14dbe37681a6a7e346fc147bb363ec7cca3180a0"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/25ad03d5c0e858c4b63f1e4b6d461d2af1b30b22"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/4a3f00262a044e8e15064b1a6860968bf0500bf4"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/6d27199ebe8cb223022150f74be13f154a964474"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/d2acc96c528d589f5827cfb90e8e9229dd9d8cb4"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/d895e66628f939edbb98608f6e033d3d39e6e546"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/f63e89a0310264264923f84406dea05fe752de62"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/f6e51b09cbaa5f6f6e6a3a9dafa666f76c37aab5"
}
],
"schema_version": "1.4.0",
"severity": []
}
Sightings
| Author | Source | Type | Date | Other |
|---|
Nomenclature
- Seen: The vulnerability was mentioned, discussed, or observed by the user.
- Confirmed: The vulnerability has been validated from an analyst's perspective.
- Published Proof of Concept: A public proof of concept is available for this vulnerability.
- Exploited: The vulnerability was observed as exploited by the user who reported the sighting.
- Patched: The vulnerability was observed as successfully patched by the user who reported the sighting.
- Not exploited: The vulnerability was not observed as exploited by the user who reported the sighting.
- Not confirmed: The user expressed doubt about the validity of the vulnerability.
- Not patched: The vulnerability was not observed as successfully patched by the user who reported the sighting.
The approach is described in our paper Mapping CVEs to MITRE ATT&CK Techniques: A Curated Gold-Set Classifier and the Limits of LLM-Assisted Label Expansion.