CVE-2026-74591

Received Received - Intake

Linux Kernel Memory Management Race Condition Fix

Publication date: 2026-08-22

Last updated on: 2026-08-25

Assigner: kernel.org

Description

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.

CVSS Scores

EPSS Scores

Probability:
Percentile:

Meta Information

Published

2026-08-22

Last Modified

2026-08-25

Generated

2026-09-12

AI Q&A

2026-08-22

EPSS Evaluated

2026-09-10

NVD

CVE-2026-74591

EUVD

EUVD-2026-64528

Affected Vendors & Products

Vendor	Product	Version / Range
linux	linux_kernel	*

Helpful Resources

Exploitability

CWE

KEV

CWE ID	Description
CWE-UNKNOWN

Attack-Flow Graph

Executive Summary

This is a Linux kernel vulnerability in the filemap component. It involves a race condition in __filemap_add_folio() where incorrect index values could be used when retrying operations after memory allocation failures. The fix ensures the original index is restored before retrying to prevent storing folios at wrong locations.

Detection Guidance

This vulnerability is specific to the Linux kernel's memory management and may not have direct detection commands. Symptoms include rare SIGILL or SIGSEGV crashes, executable text found in incorrect memory locations, or !folio_contains() debug warnings. Monitor kernel logs for such errors and ensure your kernel is updated to a patched version.

Impact Analysis

This vulnerability could cause rare system crashes like SIGILL or SIGSEGV due to executable code being placed in incorrect memory locations. It may also lead to data corruption or instability in systems running unpatched Linux kernels.

Compliance Impact

This vulnerability in the Linux kernel could lead to memory corruption, SIGILL, or SIGSEGV errors, which may cause system instability or crashes. Such failures could disrupt data processing or storage operations, potentially compromising data integrity and availability. For compliance with GDPR or HIPAA, which require data protection and system reliability, this vulnerability poses a risk if exploited, as it may lead to unauthorized access or data loss.

Mitigation Strategies

Update your Linux kernel to the latest stable version that includes the fix for this vulnerability. If immediate patching is not possible, monitor for symptoms like crashes or memory corruption and consider restricting access to affected systems until patched.

Hi! I’m here to help you understand CVE-2026-74591. Ask me anything about the vulnerability, its impact, or mitigation strategies.

0/70