CVE-2025-22015: Linux Kernel Privilege Escalation Flaw

CVE-2025-22015 Overview

CVE-2025-22015 is a NULL pointer dereference vulnerability in the Linux kernel's memory migration subsystem. The flaw exists in the __folio_migrate_mapping() function where improper handling of shmem folios during migration can lead to xarray multi-index entry corruption. When a shmem folio transitions between page cache and swap cache states, the function incorrectly uses folio_test_swapbacked() to determine the number of xarray entries to update, conflating distinct memory states and potentially corrupting sibling entries during xas_store() operations.

Critical Impact

This vulnerability can cause system denial of service through xarray data structure corruption, potentially leading to NULL pointer dereferences and kernel crashes when shmem folios are migrated between memory regions.

Affected Products

• Linux Kernel versions 6.7 through 6.12.x
• Linux Kernel versions 6.13.x prior to 6.13.3
• Linux Kernel 6.14 release candidates (rc1 through rc7)

Discovery Timeline

• April 8, 2025 - CVE-2025-22015 published to NVD
• November 3, 2025 - Last updated in NVD database

Technical Details for CVE-2025-22015

Vulnerability Analysis

The vulnerability stems from incorrect state checking logic in the kernel's memory migration path. A shmem folio maintains mutual exclusivity between page cache and swap cache residency—it can exist in one or the other, but never both simultaneously. When a folio resides in swap cache, its folio->mapping field should be NULL, indicating it is no longer associated with a shmem mapping.

The problematic code in __folio_migrate_mapping() uses folio_test_swapbacked() to determine how many xarray entries require updating during migration. However, this test returns true for both shmem folios in page cache and shmem folios in swap cache, failing to distinguish between these fundamentally different states. This conflation causes the migration code to update an incorrect number of xarray entries, transforming sibling entries into normal entries during xas_store() operations and corrupting the xarray's multi-index structure.

Additionally, the __split_huge_page() function exhibits a related issue where the check folio_test_anon() && folio_test_swapcache() for obtaining swap cache address space ignores the shmem folio in swap cache case. This could theoretically lead to NULL pointer dereferencing when splitting an in-swap-cache shmem folio, though the current implementation mitigates this through early EBUSY returns when folio->mapping is NULL.

Root Cause

The root cause is the improper use of folio_test_swapbacked() as a discriminator for xarray entry count determination. This function cannot distinguish between shmem folios that are swap-backed but still in page cache versus those that have actually been swapped out to swap cache. The fix replaces this check with folio_test_swapcache(), which correctly identifies whether the xarray is storing swap cache entries, enabling accurate determination of the xarray entry count to update.

Attack Vector

This vulnerability requires local access to exploit. An attacker with local user privileges can trigger the vulnerability by:

1. Allocating shmem-backed memory regions through shared memory or tmpfs operations
2. Inducing memory pressure or migration scenarios that cause shmem folios to transition between page cache and swap cache
3. Timing operations to hit the race condition during the xarray update phase

The migration can be triggered through NUMA memory policy changes, memory compaction operations, or direct page migration syscalls. While exploitation is complex due to timing requirements, successful attacks result in kernel memory corruption and system instability.

Detection Methods for CVE-2025-22015

Indicators of Compromise

• Kernel oops or panic messages referencing __folio_migrate_mapping() or xas_store() functions
• System crashes during heavy memory pressure scenarios involving shmem or tmpfs operations
• Dmesg entries showing NULL pointer dereferences in the memory management subsystem
• Unexpected system reboots during memory compaction or NUMA migration activities

Detection Strategies

• Monitor kernel logs for oops messages containing stack traces through __folio_migrate_mapping(), migrate_folio_move(), or related mm/migrate.c functions
• Implement kernel tracing with ftrace or eBPF to monitor folio migration paths and detect anomalous xarray operations
• Deploy crash dump analysis tooling to capture and analyze kernel panics for patterns matching this vulnerability
• Use kernel address sanitizer (KASAN) builds in development environments to detect memory corruption early

Monitoring Recommendations

• Enable kernel crash dump collection via kdump to preserve forensic evidence of exploitation attempts
• Configure syslog aggregation to centralize kernel message monitoring across affected systems
• Implement alerting on kernel panic events, particularly those occurring during memory-intensive workloads
• Monitor system uptime metrics for unexpected restarts that could indicate kernel crashes

How to Mitigate CVE-2025-22015

Immediate Actions Required

• Update affected Linux kernel installations to patched versions as soon as available from your distribution vendor
• Review systems running memory-intensive workloads with heavy shmem or tmpfs usage as higher priority for patching
• Consider temporarily reducing memory pressure on critical systems by limiting swap usage or adjusting memory overcommitment policies
• Ensure crash dump collection is enabled to capture diagnostic information if the vulnerability is triggered

Patch Information

The Linux kernel maintainers have released fixes in the following commits:

• Kernel Git Commit 29124ae980e2
• Kernel Git Commit 49100c0b070e
• Kernel Git Commit 60cf233b585c
• Kernel Git Commit 75cfb92eb632
• Kernel Git Commit c057ee03f751

Debian has also issued a security advisory addressing this vulnerability. See the Debian LTS Announcement for distribution-specific guidance.

Workarounds

• Limit or disable NUMA memory migration on affected systems using numa_balancing sysctl parameter if workload permits
• Reduce swap usage by adjusting vm.swappiness to lower values, decreasing the likelihood of shmem folio swap-out scenarios
• Consider using hugetlbfs instead of shmem/tmpfs for large shared memory allocations where applicable, as hugepages use different migration paths
• Implement application-level memory locking using mlock() for critical shmem regions to prevent migration

# Reduce swap usage to minimize vulnerability exposure
sysctl -w vm.swappiness=10

# Disable automatic NUMA balancing
sysctl -w kernel.numa_balancing=0

# Make settings persistent across reboots
echo "vm.swappiness=10" >> /etc/sysctl.d/99-cve-2025-22015-workaround.conf
echo "kernel.numa_balancing=0" >> /etc/sysctl.d/99-cve-2025-22015-workaround.conf