EUVD-2026-64528
GHSA-xwx5-8c6h-6c7v
Severity by source
AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H
Local in-kernel page-cache race, no network vector (AV:L); success needs winning a narrow timing window (AC:H); any local user triggers it (PR:L); mislocated pages can disclose, corrupt, and crash (C/I/A:H).
Primary rating from Vendor (Linux).
CVSS VectorVendor: Linux
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H
Lifecycle Timeline
5DescriptionCVE.org
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.
AnalysisAI
Memory corruption in the Linux kernel page cache (mm/filemap) arises when a race condition in __filemap_add_folio() stores a folio at an incorrect, intermediate rounded-down index after a concurrent thread resolves a conflict during the split-a-conflict retry loop. Affecting large-folio-capable kernels (6.15 onward), the flaw manifested in production as rare SIGILLs and SIGSEGVs with executable text landing a page away from its correct location, and tripped a !folio_contains() assertion under CONFIG_DEBUG_VM. …
Unlock full vulnerability intelligence
- Risk assessment & exploitation conditions
- Attack chain visualization
- Remediation with exact patch versions
- Threat intelligence from 22 sources
- Personal watchlist & email alerts
Free forever · No credit card required
Attack ChainAIDerived
Hypothetical attack flow derived from CVE metadata
Vulnerability AssessmentAI
| Exploitation | Requires local execution on a kernel with large-folio page-cache support (6.15 through the fixed releases) and hinges on a specific timing window: a new XArray node must be needed while a GFP_NOWAIT allocation fails, forcing the lock to be dropped, AND a concurrent thread must resolve the same-index conflict (for example another thread inserting a folio at that identical index) before the lock is reacquired. … Additional conditions and limiting factors are described in the full assessment. |
| Risk Assessment | The multi-source signals conflict sharply, and the auto-assigned CVSS:3.1 base score of 9.8 (AV:N/AC:L/PR:N/UI:N/C:H/I:H/A:H) is almost certainly inflated, as is common for bulk-imported Linux kernel CVEs. … Full risk analysis with EPSS, KEV, and SSVC signal comparison available after sign-in. |
| Exploit Scenario | A local workload on an unpatched large-folio kernel drives heavy concurrent file-backed mmap/read activity under memory pressure so that a GFP_NOWAIT allocation fails and the insertion lock is dropped mid-retry while another thread inserts a folio at the same index. The retry then stores the folio at a stale rounded-down index, and a subsequent access reads or executes the wrong page - surfacing as corrupted or disclosed data and SIGILL/SIGSEGV crashes. … |
| Remediation | Apply the vendor-released patch by upgrading to a fixed stable kernel - 6.18.45 or later on the 6.18 series, or the corresponding fixed build for your branch (patch trains 7.1.9 / 7.2 are also referenced) - which adds the xas_set_order() call restoring the original xas.xa_index at the bottom of the retry loop so a retry performs full re-evaluation after reacquiring the lock. … Detailed patch versions, workarounds, and compensating controls in full report. |
Recommended ActionAI
Within 24 hours, inventory all Linux systems running kernel version 6.15 or later across infrastructure and document current kernel versions by host. …
Sign in for detailed remediation steps and compensating controls.
Threat intelligence, references, and detailed analysis are available after sign-in.
Same technique Information Disclosure
View allShare
External POC / Exploit Code
Leaving vuln.today