Answer in brief
CVE-2026-80788 records a Unknown severity vulnerability in nvmet-tcp: Do not WARN on remotely-controlled oversized SGL allocations. The current sources do not mark it as known exploited. The current feed maps Linux/Linux (generic). Check affected ranges and fixed versions before updating.
Analysis pending evidence review
HOL Guard separates source facts from reviewed analysis. See the methodology.
A CVSS score is not reported in the current record. The current sources do not mark it as known exploited. Treat this as a source-backed prioritization signal, not a statement about your environment.
Analysis status
Analysis pending evidence review
Factual feed record only; HOL analysis is not approved for indexing. Read the methodology.
The current feed maps Linux/Linux (generic). Check affected ranges and fixed versions before updating.
| Package | Affected range | Fixed version |
|---|---|---|
| Linux/Linuxgeneric | >=1da177e4c3f41524e886b7f1b8a0c1fc7321cac2 <8d01f0d0e96485e39ad89b859ef85e1dc3020465 || >=1da177e4c3f41524e886b7f1b8a0c1fc7321cac2 <7b6a54d4e7b0da423c2b53ed293fd36b16c0b19e || >=1da177e4c3f41524e886b7f1b8a0c1fc7321cac2 <e7077e6c45423dd2bb7de7b5fc4b018a8e6c4741 || >=1da177e4c3f41524e886b7f1b8a0c1fc7321cac2 <86cc450022473c4a29b43a09f3ec22a9ef566dac || >=1da177e4c3f41524e886b7f1b8a0c1fc7321cac2 <c509f20be1cabda3087810bb2d658d66b3f31f35 || >=1da177e4c3f41524e886b7f1b8a0c1fc7321cac2 <9c95f7e66c62ee6c6abedcf1c04311f430ff5833 || >=1da177e4c3f41524e886b7f1b8a0c1fc7321cac2 <7fd6da0f28932442b51658bac4ff55565ca9b377 || >=1da177e4c3f41524e886b7f1b8a0c1fc7321cac2 <9b770e40bc00381e5ebf53653de5776773415be3 || >=1da177e4c3f41524e886b7f1b8a0c1fc7321cac2 <737a3b535247226f6e1a7988fd9d6e63e7d6fc71 || >=0 <5.10.267 || >=0 <5.15.218 || >=0 <6.1.185 || >=0 <6.6.154 || >=0 <6.12.106 || >=0 <6.18.47 || >=0 <7.1.11 || >=0 <7.2.1 | 8d01f0d0e96485e39ad89b859ef85e1dc3020465, 7b6a54d4e7b0da423c2b53ed293fd36b16c0b19e, e7077e6c45423dd2bb7de7b5fc4b018a8e6c4741, 86cc450022473c4a29b43a09f3ec22a9ef566dac, c509f20be1cabda3087810bb2d658d66b3f31f35, 9c95f7e66c62ee6c6abedcf1c04311f430ff5833, 7fd6da0f28932442b51658bac4ff55565ca9b377, 9b770e40bc00381e5ebf53653de5776773415be3, 737a3b535247226f6e1a7988fd9d6e63e7d6fc71, 5.10.267, 5.15.218, 6.1.185, 6.6.154, 6.12.106, 6.18.47, 7.1.11, 7.2.1 |
Published upstream
Sep 4, 2026
Evidence: source:cvelist:source_dates:source-dates:recordSource modified
Sep 4, 2026
Evidence: source:cvelist:source_dates:source-dates:recordFirst seen by HOL
Sep 4, 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.
Quoted source text, attributed separately from HOL analysis.