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/Z8idPCkaJW1IChjT@casper.infradead.org/
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.
Analysis and contextual insights are available on OpenCVE Cloud.
No vendor fix or workaround currently provided.
Additional remediation guidance may be available on OpenCVE Cloud.
Tracking
Sign in to view the affected projects.
| Source | ID | Title |
|---|---|---|
Debian DLA |
DLA-4193-1 | linux-6.1 security update |
Debian DSA |
DSA-5900-1 | linux security update |
EUVD |
EUVD-2025-10346 | 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/Z8idPCkaJW1IChjT@casper.infradead.org/ 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. |
Ubuntu USN |
USN-7605-1 | Linux kernel vulnerabilities |
Ubuntu USN |
USN-7605-2 | Linux kernel (Low Latency) vulnerabilities |
Ubuntu USN |
USN-7606-1 | Linux kernel (OEM) vulnerabilities |
Ubuntu USN |
USN-7628-1 | Linux kernel (Azure) vulnerabilities |
Ubuntu USN |
USN-7764-1 | Linux kernel vulnerabilities |
Ubuntu USN |
USN-7764-2 | Linux kernel (HWE) vulnerabilities |
Ubuntu USN |
USN-7765-1 | Linux kernel (NVIDIA) vulnerabilities |
Ubuntu USN |
USN-7766-1 | Linux kernel vulnerabilities |
Ubuntu USN |
USN-7767-1 | Linux kernel (Real-time) vulnerabilities |
Ubuntu USN |
USN-7767-2 | Linux kernel (Real-time) vulnerabilities |
Ubuntu USN |
USN-7779-1 | Linux kernel (IBM) vulnerabilities |
Ubuntu USN |
USN-7790-1 | Linux kernel (Raspberry Pi) vulnerabilities |
Ubuntu USN |
USN-7800-1 | Linux kernel (Raspberry Pi Real-time) vulnerabilities |
Ubuntu USN |
USN-7801-1 | Linux kernel (HWE) vulnerabilities |
Ubuntu USN |
USN-7802-1 | Linux kernel (Azure) vulnerabilities |
Ubuntu USN |
USN-7801-2 | Linux kernel (Oracle) vulnerabilities |
Ubuntu USN |
USN-7809-1 | Linux kernel (Azure, N-Series) vulnerabilities |
Ubuntu USN |
USN-7801-3 | Linux kernel (Oracle) vulnerabilities |
Mon, 03 Nov 2025 20:30:00 +0000
| Type | Values Removed | Values Added |
|---|---|---|
| References |
|
Tue, 28 Oct 2025 17:15:00 +0000
| Type | Values Removed | Values Added |
|---|---|---|
| CPEs | cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:* cpe:2.3:o:linux:linux_kernel:6.14:rc1:*:*:*:*:*:* cpe:2.3:o:linux:linux_kernel:6.14:rc2:*:*:*:*:*:* cpe:2.3:o:linux:linux_kernel:6.14:rc3:*:*:*:*:*:* cpe:2.3:o:linux:linux_kernel:6.14:rc4:*:*:*:*:*:* cpe:2.3:o:linux:linux_kernel:6.14:rc5:*:*:*:*:*:* cpe:2.3:o:linux:linux_kernel:6.14:rc6:*:*:*:*:*:* cpe:2.3:o:linux:linux_kernel:6.14:rc7:*:*:*:*:*:* cpe:2.3:o:linux:linux_kernel:6.7:-:*:*:*:*:*:* cpe:2.3:o:linux:linux_kernel:6.7:rc8:*:*:*:*:*:* |
Wed, 09 Apr 2025 19:30:00 +0000
| Type | Values Removed | Values Added |
|---|---|---|
| Weaknesses | CWE-476 | |
| Metrics |
threat_severity
|
threat_severity
|
Tue, 08 Apr 2025 14:15:00 +0000
| Type | Values Removed | Values Added |
|---|---|---|
| References |
| |
| Metrics |
threat_severity
|
cvssV3_1
|
Tue, 08 Apr 2025 08:30:00 +0000
| Type | Values Removed | Values Added |
|---|---|---|
| Description | 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/Z8idPCkaJW1IChjT@casper.infradead.org/ 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. | |
| Title | mm/migrate: fix shmem xarray update during migration | |
| References |
|
|
Status: PUBLISHED
Assigner: Linux
Published:
Updated: 2026-05-11T21:11:00.149Z
Reserved: 2024-12-29T08:45:45.806Z
Link: CVE-2025-22015
No data.
Status : Modified
Published: 2025-04-08T09:15:26.150
Modified: 2025-11-03T20:17:37.563
Link: CVE-2025-22015
OpenCVE Enrichment
Updated: 2025-06-23T09:16:29Z
Debian DLA
Debian DSA
EUVD
Ubuntu USN