GPU VulnDB

Database/Kernel, userspace & hypervisor

Linux kernel mm/filemap: page cache folio can be stored at the wrong index after an allocation retry

CVE-2026-74591Kernel, userspace & hypervisorcurated

Impact

In the split-a-conflict loop of __filemap_add_folio(), xas_set_order() rounds xa_index down at each stage. If a GFP_NOWAIT node allocation fails the lock is dropped and the sequence retried, but the index is not restored - so if another thread resolved the conflict meanwhile, the folio can be stored in the xarray at an intermediate, rounded-down index. The reporter saw this in production as rare SIGILLs and SIGSEGVs with executable text found a page away from where it belonged. On a busy GPU node this is silent memory corruption of file-backed data under memory pressure: jobs die with inexplicable faults, and served content can be wrong rather than merely unavailable.

Who can reach it

No attacker required - this triggers under ordinary memory pressure with large-folio page cache activity. Any workload on the node can provoke the conditions; it is not a remote or cross-tenant exploit primitive, it is a corruption bug that surfaces as unreliable execution.

What to do

Apply the patched kernel from the linked stable commits (an xas_set_order() restoring the original index at the bottom of the loop) and reboot each node. No configuration mitigation is given in the record; the symptoms stopped for the reporter only once the patch was in.

References

Related entries

All Kernel, userspace & hypervisor entries

This entry is curated: imported from vendor advisories with machine assistance, not yet individually verified. Confirm against your vendor's advisory before acting, and report anything wrong.