Answer in brief
CVE-2026-98920 records a Unknown severity vulnerability in netfs: Fix missing alloc tagging of direct mempool allocations. The current sources do not mark it as known exploited. The current feed maps Linux/Linux (generic), 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), Linux/Linux (generic). Check affected ranges and fixed versions before updating.
| Package | Affected range | Fixed version |
|---|---|---|
| Linux/Linuxgeneric | >=15ed8a9b7c63e9171f5139a6aaa1ffb61809861f <5c03da745171485fd181f17b69213464f6d05f3d || >=1d78d56c43ef3768183e8370e7367b162700e049 <37a2042748bc880df03ff8315db86ed82991fbb8 || >=1d78d56c43ef3768183e8370e7367b162700e049 <b78b728e21c32ec4c330b299f657fb1eb02dffc2 || b343252d6f536203dd0660f676190dcbf6d2ecdc || 3f6d7f8a5416d852648d15a05e895f1195ee8a85 || >=6.12.114 <6.13 || >=7.1.8 <7.2 | 5c03da745171485fd181f17b69213464f6d05f3d, 37a2042748bc880df03ff8315db86ed82991fbb8, b78b728e21c32ec4c330b299f657fb1eb02dffc2, 6.13, 7.2 |
| Linux/Linuxgeneric | 7.2 | Not reported |
Published upstream
Oct 23, 2026
Evidence: source:cvelist:source_dates:source-dates:recordSource modified
Oct 23, 2026
Evidence: source:cvelist:source_dates:source-dates:recordFirst seen by HOL
Oct 23, 2026
In the Linux kernel, the following vulnerability has been resolved: netfs: Fix missing alloc tagging of direct mempool allocations Commit 1d78d56c43ef ("netfs: Fix folio_queue ENOMEM in writeback by adding a mempool") added a mempool for the folio_queues and made the request, subrequest and folio_queue allocations distinguish between writeback and everything else. Writeback is part of memory reclaim and must not fail due to ENOMEM, so it allocates under GFP_NOFS through mempool_alloc(), which may dip into the pool's reserve and, if that runs empty, wait for elements to be returned. The GFP_KERNEL paths, which can return -ENOMEM to their callers, invoke the pool's ->alloc() callback directly instead. The direct call, however, skips the alloc_hooks() wrapper that the mempool_alloc() macro provides. The pool callbacks, mempool_alloc_slab() and mempool_kmalloc(), call kmem_cache_alloc_noprof() and kmalloc_noprof() and rely on current->alloc_tag having been set by the caller. With CONFIG_MEM_ALLOC_PROFILING_DEBUG=y this leads to current->alloc_tag not set WARNING: ./include/linux/alloc_tag.h:161 at __alloc_tagging_slab_alloc_hook alloc_tag was not set WARNING: ./include/linux/alloc_tag.h:166 at __alloc_tagging_slab_free_hook at allocation and free time respectively, as reported when reading files on a CIFS mount. The allocations are also missing from /proc/allocinfo. Wrap the direct ->alloc() invocations in alloc_hooks() with a new mempool_alloc_noreserve() helper in include/linux/mempool.h, next to the other alloc_hooks()-wrapped macros such as mempool_alloc(). The GFP_KERNEL paths keep their failable allocation semantics, they just get tagged now.
Quoted source text, attributed separately from HOL analysis.