CVE-2025-22015

What it actually does

Incorrect xarray entry count calculation in __folio_migrate_mapping() for shmem folios in swap cache corrupts multi-index entries by converting sibling entries to normal entries during xas_store(); a related path in __split_huge_page() can dereference NULL when a swap-cached shmem folio is split.

Why it matters to the business

Kernel memory corruption on Linux systems can cause crashes, data loss, or escalation to full system compromise; widespread kernel deployment and downstream package prevalence increase operational risk and patching urgency across servers and containers.

How an attack unfolds

An attacker with local access crafts workloads that place shmem folios into the swap cache then forces migration or huge-page splitting, triggering the flawed xarray update path to corrupt kernel structures and potentially chain into privilege-escalation primitives seen in related kernel CVEs.

How to fix it

Upgrade the Linux kernel to 6.1.132 or later; for Red Hat Enterprise Linux 9.0 EUS apply the 5.14.0-70.49.1.el9_0 package set (kernel, kernel-core, kernel-modules, bpftool, and related debuginfo/devel packages) and reboot.

How to confirm the fix worked

Verify running kernel version matches or exceeds the fixed releases; inspect /proc/version and package manager output for the listed fixed versions; confirm absence of the buggy __folio_migrate_mapping logic via source or symbol checks.

Typical attack path

1. Obtain local execution on a Linux host
2. Create shmem mappings and force the folio into swap cache
3. Trigger folio migration or split_huge_page_to_list_to_order()
4. Exploit resulting xarray corruption for memory write primitives
5. Escalate to kernel code execution or denial of service

How to detect it

Search kernel logs for oops/panic messages referencing __folio_migrate_mapping, xas_store, shmem, swapcache or folio migration; inspect auditd and syslog for unusual shmem or swap activity preceding crashes; correlate with process creation of local workloads that heavily use tmpfs or swap.

What your security team should do

• Immediately schedule kernel upgrades to the fixed versions on all affected systems
• Prioritize internet-facing and multi-tenant hosts given ecosystem prevalence
• Enable kernel crash-dump collection and monitor for xarray or migration-related oops
• Review compensating controls such as seccomp and namespace restrictions until patched