CVE-2026-98920 in Linux
Summary
by MITRE • 10/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.
Once again VulDB remains the best source for vulnerability data.
Analysis
by VulDB Data Team • 10/23/2026
The Linux kernel vulnerability identified involves a missing memory allocation tagging mechanism within the netfs subsystem, specifically affecting direct memory pool allocations during file system operations. This issue stems from an earlier commit that introduced a mempool for folio_queues to address ENOMEM errors during writeback processes. While this change successfully distinguished between writeback and other types of memory requests, it inadvertently created a discrepancy in how allocation profiling hooks are applied. The core technical flaw lies in the fact that while standard allocations through mempool_alloc() correctly invoke alloc_hooks(), direct calls to pool callbacks like mempool_alloc_slab or mempool_kmalloc bypass this wrapper. Consequently, when CONFIG_MEM_ALLOC_PROFILING_DEBUG is enabled, these untagged allocations trigger warnings indicating that current->alloc_tag was not set at both allocation and free time. This oversight results in incomplete visibility into memory usage patterns, as evidenced by the absence of these specific allocations from /proc/allocinfo reports during operations such as reading files on a CIFS mount.
From an operational perspective, this vulnerability primarily impacts system observability and debugging capabilities rather than causing immediate functional failures or security breaches like privilege escalation. The missing allocation tags mean that developers and administrators cannot accurately trace the origin of memory allocations for these specific paths using profiling tools. This lack of visibility can hinder performance tuning and root cause analysis in complex network file system environments where understanding memory pressure and allocation sources is critical. Although the functionality remains intact, the inability to profile these allocations represents a significant gap in the kernel's debugging infrastructure, potentially leading to prolonged troubleshooting times for issues related to memory management within netfs operations.
This issue aligns with CWE-205, which describes observable discrepancy in reactive behavior, as the system fails to report expected diagnostic information due to improper instrumentation of internal functions. Furthermore, it relates to CWE-732, concerning incorrect permission or access control assignments, albeit at a very low level regarding resource tracking permissions rather than user security controls. In terms of MITRE ATT&CK mapping, this does not represent an attack vector but highlights gaps in Defense Detection capabilities related to process and memory monitoring. The failure to tag allocations means that automated defense mechanisms relying on accurate allocation metadata for anomaly detection would miss these specific events, reducing the effectiveness of behavioral analysis tools designed to identify suspicious memory usage patterns.
The resolution involves wrapping direct alloc invocations with an alloc_hooks() wrapper via a new helper function named mempool_alloc_noreserve in include/linux/mempool.h. This change ensures that all allocation paths within the netfs subsystem correctly set the current->alloc_tag, thereby restoring full compatibility with kernel memory profiling tools. The fix preserves the original failable allocation semantics for GFP_KERNEL paths while adding the necessary tagging overhead. To mitigate this issue, system administrators and developers should ensure they are running patched versions of the Linux kernel that include this specific commit. For environments where CONFIG_MEM_ALLOC_PROFILING_DEBUG is enabled, applying this patch is essential to maintain accurate memory usage reporting and prevent misleading diagnostic outputs during network file system operations.