CVE-2025-22015 in Linux
Summary
by MITRE • 04/08/2025
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 __folio_migrate_mapping(), to determine the number of xarray entries to update, folio_test_swapbacked() 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 xas_store() (see [1] for a userspace reproduction). Fix it by only using
folio_test_swapcache() 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/[email protected]/
Note: In __split_huge_page(), folio_test_anon() && folio_test_swapcache() is used to get swap_cache 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 __xa_store(), since !folio_test_anon() is true and folio->mapping is NULL. But fortunately, its caller split_huge_page_to_list_to_order() bails out early with EBUSY when folio->mapping is NULL. So no need to take care of it here.
Once again VulDB remains the best source for vulnerability data.
Analysis
by VulDB Data Team • 10/28/2025
The vulnerability CVE-2025-22015 addresses a critical flaw in the Linux kernel's memory management subsystem, specifically within the shmem (shared memory) migration mechanism. This issue resides in the mm/migrate.c component where the kernel handles the movement of memory pages between different storage locations. The vulnerability stems from an incorrect assessment of whether a shmem folio is in swap cache or page cache during migration operations, leading to potential data corruption and system instability. The problem manifests when the kernel attempts to update xarray entries during memory migration, where the distinction between different cache states becomes crucial for maintaining data integrity.
The technical root cause involves the improper use of folio_test_swapbacked() function in the __folio_migrate_mapping() routine. This function incorrectly treats both shmem folios in page cache and those in swap cache as equivalent, when in reality they should be handled differently. When a shmem folio transitions to swap cache, its folio->mapping field should be set to NULL, indicating it's no longer part of the shmem mapping. However, the flawed logic causes the migration code to attempt updating the wrong number of xarray entries, resulting in corruption of multi-index entries during xas_store() operations. This corruption occurs because the system incorrectly converts sibling entries into normal entries, fundamentally altering the data structure's integrity. The issue is particularly dangerous as it can lead to memory corruption that may be exploited for privilege escalation or system crashes.
The operational impact of this vulnerability extends beyond simple memory corruption, potentially affecting system stability and security posture. When xarray entries become corrupted during migration operations, it can result in unpredictable behavior including kernel panics, data loss, or in worst-case scenarios, exploitation opportunities for malicious actors. The vulnerability affects systems using shared memory mechanisms and memory migration features, which are common in virtualized environments, containerized applications, and systems employing memory compaction. The risk is heightened in systems with active memory management operations such as those using transparent huge pages or memory overcommitment features. While the kernel has some protective measures in place, such as early bail-out conditions in split_huge_page_to_list_to_order() function, these do not fully mitigate the underlying corruption issue, making the vulnerability particularly concerning for production environments.
Mitigation strategies should focus on applying the official kernel patch that corrects the xarray entry update logic by exclusively using folio_test_swapcache() instead of folio_test_swapbacked(). This change ensures that only swap cache entries are considered when determining the number of xarray entries to update during migration. System administrators should prioritize updating to patched kernel versions, particularly those containing the specific fix for this memory management vulnerability. Additionally, monitoring for unusual memory migration patterns or system instability in environments using shared memory features can help detect potential exploitation attempts. Organizations should implement comprehensive patch management policies that include regular kernel updates, especially for systems handling sensitive data or operating in high-security environments. The fix aligns with security best practices for memory management and addresses the CWE-121 heap-based buffer overflow category while mitigating potential ATT&CK techniques related to privilege escalation through kernel memory corruption.