CVE-2025-22015

Source
https://nvd.nist.gov/vuln/detail/CVE-2025-22015
Import Source
https://storage.googleapis.com/cve-osv-conversion/osv-output/CVE-2025-22015.json
JSON Data
https://api.osv.dev/v1/vulns/CVE-2025-22015
Downstream
Related
Published
2025-04-08T09:15:26Z
Modified
2025-08-09T19:01:27Z
Summary
[none]
Details

In the Linux kernel, the following vulnerability has been resolved:

mm/migrate: fix shmem xarray update during migration

A shmem folio can be either in page cache or in swap cache, but not at the same time. Namely, once it is in swap cache, folio->mapping should be NULL, and the folio is no longer in a shmem mapping.

In _foliomigratemapping(), to determine the number of xarray entries to update, foliotestswapbacked() is used, but that conflates shmem in page cache case and shmem in swap cache case. It leads to xarray multi-index entry corruption, since it turns a sibling entry to a normal entry during xasstore() (see [1] for a userspace reproduction). Fix it by only using foliotestswapcache() to determine whether xarray is storing swap cache entries or not to choose the right number of xarray entries to update.

[1] https://lore.kernel.org/linux-mm/Z8idPCkaJW1IChjT@casper.infradead.org/

Note: In _splithugepage(), foliotestanon() && foliotestswapcache() is used to get swapcache address space, but that ignores the shmem folio in swap cache case. It could lead to NULL pointer dereferencing when a in-swap-cache shmem folio is split at _xastore(), since !foliotestanon() is true and folio->mapping is NULL. But fortunately, its caller splithugepagetolisttoorder() bails out early with EBUSY when folio->mapping is NULL. So no need to take care of it here.

References

Affected packages