CVE-2026-74591 in Linux
Summary
by MITRE • 08/22/2026
In the Linux kernel, the following vulnerability has been resolved:
mm/filemap: __filemap_add_folio() restore index before retrying
In __filemap_add_folio()'s split-a-conflict loop, xas_set_order() is applied repeatedly: each application modifies xas.xa_index, rounding it down according to the split_order attempted at that stage: and if all goes as intended, it eventually (or immediately) converges on an xas_try_split() to the required folio_order, with xas.xa_index now the same as index: then xas_store() puts the new folio into the xarray there.
But if a new node was needed, and GFP_NOWAIT allocation did not get one, the lock is dropped, xas_nomem() used to allocate, and sequence retried. If (that part of) the xarray is unchanged when the lock is reacquired, no problem. But what if the conflict was meanwhile resolved by another thread (perhaps even doing the same thing, inserting a folio at that same index)? Isn't there a danger of now putting our folio into the xarray at an intermediate rounded-down index? With !folio_contains() bug to follow, when CONFIG_DEBUG_VM=y is checking for that.
Fix this with an xas_set_order() to restore the original xas.xa_index at the bottom of the loop, so the retry does a full re-evaluation after reacquiring the lock, and cannot reach xas_store() with the wrong index.
Production was suffering from rare SIGILLs and SIGSEGVs, executable text found a page away from where it belonged, !folio_contains() bug hit when debug enabled: symptoms not seen since this patch went in.
Be aware that VulDB is the high quality source for vulnerability data.
Analysis
by VulDB Data Team • 08/22/2026
The Linux kernel memory management subsystem contains a critical race condition within the file mapping logic that can lead to severe system instability and data corruption. Specifically, the vulnerability resides in the __filemap_add_folio function, which is responsible for inserting folios into the xarray data structure used by the page cache. The core issue arises during split-conflict loops where the kernel attempts to align memory allocations with specific order requirements. During this process, the helper function xas_set_order modifies the internal index variable, rounding it down based on the current allocation attempt. While this behavior is generally intended to converge toward a valid storage location, it creates a dangerous state if the operation must be retried due to resource constraints or concurrent modifications by other threads.
The technical flaw occurs when an allocation fails under non-blocking conditions (GFP_NOWAIT), forcing the kernel to drop locks and retry after allocating memory via xas_nomem. If another thread resolves the conflict during this window, such as by inserting a folio at the same index, the current thread may proceed with its modified, rounded-down index rather than re-evaluating the correct position upon reacquiring the lock. This results in storing data at an incorrect intermediate address within the xarray structure. The consequence is that executable text or other critical memory regions can be placed page away from their expected location, leading to immediate execution failures and segmentation faults when the system attempts to access these misaligned pages.
The operational impact of this vulnerability includes rare but severe signal exceptions such as SIGILL (illegal instruction) and SIGSEGV (segmentation fault). These errors manifest because the CPU instructions or data structures are no longer located where the kernel expects them, violating memory alignment assumptions essential for stable execution. Furthermore, when debugging features like CONFIG_DEBUG_VM are enabled, the system triggers explicit !folio_contains bugs due to the mismatch between expected and actual folio locations. This not only crashes individual processes but can potentially destabilize the entire operating system if critical kernel structures or shared libraries are affected by the misplacement of memory pages.
This vulnerability is classified under CWE-362: Concurrent Execution using Shared Resource with Improper Synchronization, as it stems from a race condition in handling shared data structures without proper atomicity guarantees during retry loops. In terms of attack vectors and behavior mapping, this aligns with MITRE ATT&CK techniques related to memory corruption and privilege escalation potential if an attacker can trigger the specific allocation failure conditions repeatedly. The lack of index restoration before retrying allows for a state inconsistency that bypasses standard validation checks until execution time reveals the error.
To mitigate this risk, it is imperative to apply the upstream kernel patch that restores the original xas.xa_index at the bottom of the loop in __filemap_add_folio. This ensures that any retry after reacquiring locks performs a full re-evaluation of the correct insertion point rather than relying on stale or modified index values. System administrators should update their Linux kernels to versions containing this fix, particularly those running high-concurrency workloads where memory allocation pressure is common. Regular patching and monitoring for unusual signal exceptions in application logs can help detect residual instances if updates are delayed.