CVE-2026-74591 - Vulnerability Details

- mm/filemap: __filemap_add_folio() restore index before retrying

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: 9.8 Critical

EPSS: < 1% Very Low

KEV: No

Impact:

Action:

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

The EPSS score is less than 1% and the vulnerability is not listed in CISA’s KEV catalog, indicating no documented exploitation. The CVSS score of 9.8 indicates high severity. 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.

Default status is the baseline for the product, each version can override it (e.g. patched versions marked unaffected).

Vendor Product Default status Versions

Linux

unaffected

Version	Status	Constraints
`200a89c159a7a416115e6e309183c82183bf98aa`	affected	< 4917e3ebcab50f0265e8ca01c8567de4c4a47511
`200a89c159a7a416115e6e309183c82183bf98aa`	affected	< 267ecd2eb7759c26f1a026eb0a5b231071534c9c
`200a89c159a7a416115e6e309183c82183bf98aa`	affected	< 86da3f7e1e609e1e8bfbab198af68467c5a015a5

Linux

affected

Version	Status	Constraints
`6.15`	affected	—
`0`	unaffected	< 6.15
`6.18.45`	unaffected	≤ 6.18.*
`7.1.9`	unaffected	≤ 7.1.*
`7.2`	unaffected	≤ *

No data.

Vendor Product Confidence Versions

Linux

Linux Kernel

99%

Version	Status	Scheme	Platform
`[200a89c159a7a416115e6e309183c82183bf98aa,4917e3ebcab50f0265e8ca01c8567de4c4a47511)`	affected	code_commit	—
`[200a89c159a7a416115e6e309183c82183bf98aa,267ecd2eb7759c26f1a026eb0a5b231071534c9c)`	affected	code_commit	—
`[200a89c159a7a416115e6e309183c82183bf98aa,86da3f7e1e609e1e8bfbab198af68467c5a015a5)`	affected	code_commit	—

Linux

Linux Kernel

99%

Version	Status	Scheme	Platform
`6.15`	affected	generic	—
`[0,6.15)`	unaffected	semver	—
`[6.18.45,6.19.0)`	unaffected	semver	—
`[7.1.9,7.2.0)`	unaffected	semver	—
`[7.2,*]`	unaffected	generic	—

Found an issue or want to improve our Enrichment? You can suggest it directly by opening an issue on our dedicated GitHub repository .

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 25, 2026 at 06:24 UTC.

Tracking

Sign in to view the affected projects.

Advisories

No advisories yet.

No CVSS v4.0

Attack Vector Network

Attack Complexity Low

Privileges Required None

Scope Unchanged

Confidentiality Impact High

Integrity Impact High

Availability Impact High

User Interaction None

No CVSS v3.0

No CVSS v2

This CVE is not in the KEV list.

The EPSS score is 0.00442.

Key SSVC decision points have not yet been added.

References

Link	Providers
https://git.kernel.org/stable/c/267ecd2eb7759c26f1a026eb0a5b231071534c9c
https://git.kernel.org/stable/c/4917e3ebcab50f0265e8ca01c8567de4c4a47511
https://git.kernel.org/stable/c/86da3f7e1e609e1e8bfbab198af68467c5a015a5
https://lore.kernel.org/linux-cve-announce/2026082213-CVE-2026-74591-72ed@gregkh/T
https://nvd.nist.gov/vuln/detail/CVE-2026-74591
https://www.cve.org/CVERecord?id=CVE-2026-74591

History

Tue, 25 Aug 2026 05:45:00 +0000

Type	Values Removed	Values Added
Metrics	cvssV3_1 `{'score': 7.0, 'vector': 'CVSS:3.1/AV:L/AC:H/PR:L/UI:N/S:U/C:H/I:H/A:H'}`	cvssV3_1 `{'score': 9.8, 'vector': 'CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H'}`

Mon, 24 Aug 2026 14:15:00 +0000

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

Mon, 24 Aug 2026 12:15:00 +0000

Type	Values Removed	Values Added
Weaknesses		CWE-367
References		https://lore.kernel.org/linux-cve-announce/2026082213-CVE-2026-74591-72ed@gregkh/T https://nvd.nist.gov/vuln/detail/CVE-2026-74591 https://www.cve.org/CVERecord?id=CVE-2026-74591
Metrics	threat_severity `None`	cvssV3_1 `{'score': 7.0, 'vector': 'CVSS:3.1/AV:L/AC:H/PR:L/UI:N/S:U/C:H/I:H/A:H'}` threat_severity `Moderate`

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		https://git.kernel.org/stable/c/267ecd2eb7759c26f1a026eb0a5b231071534c9c https://git.kernel.org/stable/c/4917e3ebcab50f0265e8ca01c8567de4c4a47511 https://git.kernel.org/stable/c/86da3f7e1e609e1e8bfbab198af68467c5a015a5

Subscriptions

Linux Linux Kernel

MITRE

Status: PUBLISHED

Assigner: Linux

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

Updated: 2026-08-25T05:40:18.794Z

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

Link: CVE-2026-74591

Vulnrichment

No data.

NVD

Status : Received

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

Modified: 2026-08-25T06:18:34.397

Link: CVE-2026-74591

Redhat

Severity : Moderate

Publid Date: 2026-08-22T00:00:00Z

Links: CVE-2026-74591 - Bugzilla

OpenCVE Enrichment

Updated: 2026-08-25T06:30:04Z

Weaknesses

CWE-367
Time-of-check Time-of-use (TOCTOU) Race Condition

Impact

Affected Systems

Risk and Exploitability

Tracking

Attack Vector Network

Attack Complexity Low

Privileges Required None

Scope Unchanged

Confidentiality Impact High

Integrity Impact High

Availability Impact High

User Interaction None

Subscriptions

JSON object

JSON object

JSON object

JSON object

JSON object