All vulnerabilities
CVE-2026-98920

Linux: netfs: Fix missing alloc tagging of direct mempool allocations

Linux LinuxOperating systems
CVSS
NoneNot scored
ExploitationNo known exploitationNot in CISA KEV, which does not prove it is unexploitedCISA KEV
Exploit odds (EPSS)No scoreNo FIRST EPSS score in this snapshot yet
Fixed in5c03da745171485fd181f17b69213464f6d05f3dAlso 37a2042748bc880df03ff8315db86ed82991fbb8, 6.13 and 1 moreCVE List
Published23 Oct 2026Updated 23 Oct 2026CVE List

What fixes it

A fixed version on one release line is not the upgrade target for every line. Check your exact version and any vendor backports.

Description

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.

Text from CVE List

Affected versions 11

  • Linuxaffected: 15ed8a9b7c63e9171f5139a6aaa1ffb61809861f before 5c03da745171485fd181f17b69213464f6d05f3dCVE List
  • Linuxaffected: 1d78d56c43ef3768183e8370e7367b162700e049 before 37a2042748bc880df03ff8315db86ed82991fbb8CVE List
  • Linuxaffected: 1d78d56c43ef3768183e8370e7367b162700e049 before b78b728e21c32ec4c330b299f657fb1eb02dffc2CVE List
  • Linuxaffected: b343252d6f536203dd0660f676190dcbf6d2ecdcCVE List
  • Linuxaffected: 3f6d7f8a5416d852648d15a05e895f1195ee8a85CVE List
  • Linuxaffected: 6.12.114 before 6.13CVE List
  • Linuxaffected: 7.1.8 before 7.2CVE List
  • Linuxaffected: 7.2CVE List
  • Linuxunaffected: all versions before 7.2CVE List
  • Linuxunaffected: 7.2.9 through 7.2.*CVE List
  • Linuxunaffected: 7.3CVE List

References 3