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.
Published: 2026-08-22
Score: n/a
EPSS: n/a
KEV: No
Impact: n/a
Action: n/a
AI Analysis

Impact

The flaw occurs in the Linux kernel memory‑management subsystem. When adding a folio to an xarray during a split conflict the retry logic does not restore the original index. If a competing thread resolves the conflict before the retry, the index is rounded down and the subsequent store writes to a wrong location, corrupting kernel memory. The effect is kernel panics manifested as SIGILL or SIGSEGV.

Affected Systems

All Linux kernel builds that contain the vulnerable __filemap_add_folio() code path are potentially affected; the advisory does not list specific kernel versions.

Risk and Exploitability

No EPSS score is available and the vulnerability is not listed in CISA’s KEV catalog, indicating no documented exploitation. Based on the description it is inferred that a local user or privileged process that triggers file mapping or filesystem activity could invoke the fault path, causing a denial‑of‑service kernel crash.

Generated by OpenCVE AI on August 22, 2026 at 16:25 UTC.

Remediation

No vendor fix or workaround currently provided.

OpenCVE Recommended Actions

  • Upgrade the kernel to a version that includes the __filemap_add_folio() index restoration patch.
  • If an immediate kernel upgrade cannot be performed, consider disabling CONFIG_DEBUG_VM in the kernel configuration to avoid the debug path that exposes the bug.
  • Reboot the system after the kernel change to ensure the patched code is loaded and stale state is cleared.

Generated by OpenCVE AI on August 22, 2026 at 16:25 UTC.

Tracking

Sign in to view the affected projects.

Advisories

No advisories yet.

History

Sat, 22 Aug 2026 16:45:00 +0000

Type Values Removed Values Added
Weaknesses CWE-362
CWE-682

Sat, 22 Aug 2026 15:45:00 +0000

Type Values Removed Values Added
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.
Title mm/filemap: __filemap_add_folio() restore index before retrying
First Time appeared Linux
Linux linux Kernel
CPEs cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*
Vendors & Products Linux
Linux linux Kernel
References

Subscriptions

Linux Linux Kernel
cve-icon MITRE

Status: PUBLISHED

Assigner: Linux

Published:

Updated: 2026-08-22T15:31:42.661Z

Reserved: 2026-08-15T05:44:03.918Z

Link: CVE-2026-74591

cve-icon Vulnrichment

No data.

cve-icon NVD

Status : Received

Published: 2026-08-22T16:16:31.353

Modified: 2026-08-22T16:16:31.353

Link: CVE-2026-74591

cve-icon Redhat

No data.

cve-icon OpenCVE Enrichment

Updated: 2026-08-22T16:45:03Z

Weaknesses
  • CWE-362

    Concurrent Execution using Shared Resource with Improper Synchronization ('Race Condition')

  • CWE-682

    Incorrect Calculation