CVE-2026-74591: Linux Kernel Race Condition Vulnerability

CVE-2026-74591 Overview

CVE-2026-74591 is a race condition in the Linux kernel memory management subsystem. The flaw resides in __filemap_add_folio() within mm/filemap.c. When the split-a-conflict loop drops the xarray lock to perform a GFP_NOWAIT allocation retry, xas.xa_index retains an intermediate rounded-down value from a prior xas_set_order() call. If another thread resolves the conflict concurrently, the retry can store a folio at the wrong xarray index. The result is executable text mapped a page away from where it belongs, producing rare SIGILL and SIGSEGV signals in production workloads.

Critical Impact
Concurrent page cache insertions can place folios at incorrect xarray indices, corrupting process memory mappings and causing crashes or arbitrary code behavior.

Affected Products

Linux kernel with CONFIG_TRANSPARENT_HUGEPAGE and page cache large folio support
Distributions shipping vulnerable stable kernel branches referenced in the upstream commits
Systems where __filemap_add_folio() handles conflicting entries requiring xarray splits

Discovery Timeline

2026-08-22 - CVE-2026-74591 published to the National Vulnerability Database
2026-08-25 - Last updated in NVD database

Technical Details for CVE-2026-74591

Vulnerability Analysis

The defect is a race condition [CWE-362] in the page cache folio insertion path. Inside __filemap_add_folio(), the split-a-conflict loop invokes xas_set_order() repeatedly. Each call rounds xas.xa_index down according to the current split_order. Under normal execution, the loop converges on xas_try_split() at the required folio_order, with xas.xa_index equal to the caller-supplied index, and xas_store() places the new folio at that index.

When a new xarray node is required and the GFP_NOWAIT allocation fails, the code drops the lock, calls xas_nomem() to allocate memory, and retries the sequence. If the xarray state is unchanged after reacquiring the lock, the retry proceeds correctly. If another thread resolves the conflict during the window, the retry re-enters the loop with xas.xa_index still holding an intermediate rounded-down value.

The retry can then reach xas_store() with an incorrect index. The folio is inserted at the wrong slot. Downstream, the !folio_contains() assertion fires under CONFIG_DEBUG_VM=y, and production systems observe executable text located one page away from its intended offset.

Root Cause

The root cause is failure to restore xas.xa_index to the caller's original index before retrying the loop after xas_nomem(). The fix adds an xas_set_order() call at the bottom of the loop to force full re-evaluation on retry.

Attack Vector

Exploitation requires triggering concurrent large-folio insertions at the same page cache index while inducing memory pressure to force GFP_NOWAIT failure. The condition is timing-dependent and non-deterministic. Observed real-world impact includes memory corruption in executable mappings, producing SIGILL and SIGSEGV in unrelated user processes.

// See upstream kernel commits for the patch diff:
// git.kernel.org/stable/c/267ecd2eb7759c26f1a026eb0a5b231071534c9c
// git.kernel.org/stable/c/4917e3ebcab50f0265e8ca01c8567de4c4a47511
// git.kernel.org/stable/c/86da3f7e1e609e1e8bfbab198af68467c5a015a5

Detection Methods for CVE-2026-74591

Indicators of Compromise

Unexplained SIGILL and SIGSEGV signals in long-running production workloads without corresponding application changes
Kernel warnings referencing !folio_contains() when CONFIG_DEBUG_VM=y is enabled
Executable text page faults where the faulting instruction address is offset one page from the expected mapping

Detection Strategies

Enable CONFIG_DEBUG_VM on non-production kernels to surface the !folio_contains() assertion during testing
Correlate dmesg output with process crash telemetry to identify page cache anomalies
Compare running kernel versions against the fixed commits listed in the upstream references

Monitoring Recommendations

Ingest kernel logs into a centralized data lake and alert on folio_contains and page cache warning patterns
Track SIGILL and SIGSEGV rates per host and flag statistical anomalies against baseline
Monitor kernel build metadata across the fleet to identify hosts running unpatched stable branches

How to Mitigate CVE-2026-74591

Immediate Actions Required

Identify all Linux hosts running stable kernel branches that predate the fix commits 267ecd2e, 4917e3eb, and 86da3f7e
Schedule kernel upgrades to distribution builds that incorporate the __filemap_add_folio() index restoration fix
Prioritize hosts under memory pressure or running workloads that exercise large-folio page cache paths

Patch Information

Apply the upstream fix that adds xas_set_order() at the bottom of the split-a-conflict retry loop. The patch is available in the Kernel Commit 267ecd2e, Kernel Commit 4917e3eb, and Kernel Commit 86da3f7e. Rebuild custom kernels from stable branches that include these commits, or update to vendor-provided packages incorporating the fix.

Workarounds

Disable transparent huge pages for the page cache on affected workloads to reduce exposure to the large-folio insertion path
Reduce memory pressure to lower the frequency of GFP_NOWAIT allocation failures that trigger the retry loop
Restrict untrusted workloads on unpatched hosts until a fixed kernel is deployed

bash

# Verify running kernel version and check for patched commit
uname -r
# On distributions with source-installed kernels, confirm the fix:
git -C /usr/src/linux log --oneline | grep -E '267ecd2e|4917e3eb|86da3f7e'