CVE-2026-98920

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.