Cloudanix VulnDB

CVE-2026-98920

None

CVSS

—

EPSS

0.2%

Published

Oct 23, 2026

CISA due date

—

Cloudanix analysis

Monitor only SSVC: Track

A Linux kernel tracking issue for certain memory operations could generate warning messages and incomplete usage reports during file access on network shares.

Exploitation
Other
Attacker needs
None
Complexity
Theoretical
Impact
Other
Component
OS kernel
Class
Other
Remediation
Upgrade
Effort
Medium
Patch risk
Low

What it actually does

Direct invocation of mempool ->alloc callbacks (mempool_alloc_slab and mempool_kmalloc) bypasses alloc_hooks wrappers, leaving current->alloc_tag unset and causing warnings at allocation and free time under CONFIG_MEM_ALLOC_PROFILING_DEBUG while omitting entries from /proc/allocinfo.

Why it matters to the business

Kernel builds with memory allocation profiling debug enabled may log repeated warnings and produce incomplete memory accounting data during netfs writeback and CIFS operations, complicating performance troubleshooting without affecting core functionality.

How an attack unfolds

No attacker exploitation path exists; the condition surfaces automatically when GFP_KERNEL allocation paths in netfs exercise the direct callback during normal filesystem I/O such as reading files on a CIFS mount.

How to fix it

Apply the upstream fix introducing mempool_alloc_noreserve helper that wraps direct ->alloc calls with alloc_hooks; rebuild and deploy updated kernel images containing commit that resolves the tagging omission.

How to confirm the fix worked

Boot with CONFIG_MEM_ALLOC_PROFILING_DEBUG=y, perform CIFS file operations, and confirm absence of alloc_tag.h warnings together with correct population of allocation statistics in /proc/allocinfo.

Typical attack path

  1. Mount CIFS share and trigger writeback or read operations
  2. Kernel executes GFP_KERNEL mempool direct alloc path
  3. alloc_tag remains unset producing warnings and missing /proc/allocinfo entries

How to detect it

Search kernel logs and dmesg for alloc_tag unset warnings referencing include/linux/alloc_tag.h during CIFS or netfs activity; inspect /proc/allocinfo for missing netfs writeback entries.

  • current->alloc_tag not set
  • WARNING: ./include/linux/alloc_tag.h:161 at __alloc_tagging_slab_alloc_hook
  • WARNING: ./include/linux/alloc_tag.h:166 at __alloc_tagging_slab_free_hook
  • alloc_tag was not set

What your security team should do

  • Prioritize kernel updates containing the mempool_alloc_noreserve change within standard patch cycles
  • Review kernel configs to determine exposure of debug profiling builds in production
  • Add alloc_tag warning patterns to kernel log monitoring for early visibility

The record

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.

Affected packages

Ecosystem Package Introduced Fixed