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

mm/huge_memory: use correct flags for device private PMD entry

Commit 65edfda6f3f2 ("mm/rmap: extend rmap and migration support
device-private entries") updated set_pmd_migration_entry() to use
pmdp_huge_get_and_clear() in the softleaf case, but made no further
adjustments to the function itself.

Therefore this function continues to incorrectly use pmd_write(),
pmd_soft_dirty() and pmd_uffd_wp() to determine whether the installed
migration entry should be marked writable, softdirty or uffd-wp
respectively.

Whilst all are incorrect, the most problematic of these is pmd_write(), as
this can lead to corrupted rmap state.

On x86-64 _PAGE_SWP_SOFT_DIRTY is aliased to _PAGE_RW. So calling
pmd_write() on a softleaf will return the softdirty state encoded in the
entry, assuming CONFIG_MEM_SOFT_DIRTY was enabled.

This was observed when running the hmm.hmm_device_private.anon_write_child
selftest:

1. The test faults in a range then migrates it such that a device-private
THP range is established.

2. The parent then migrates it to a device-private writable PMD entry whose
folio is entirely AnonExclusive with entire_mapcount=1, softdirty set
(accidentally correct write state).

3. The parent forks and the PMD entries are set to device-private read only
entries, entire_mapcount=2, softdirty still set.

4. [BUG] The child writes to the range then migrates to RAM - intending to
install non-writable migration entries - but replacing parent and child
PMD mappings with WRITABLE entries due to misinterpreting the softdirty
bit.

5. In remove_migration_pmd(), if !softleaf_is_migration_read(entry) we
set the RMAP_EXCLUSIVE flag when calling folio_add_anon_rmap_pmd() for
both parent and child, which are therefore AnonExclusive.

6. [SPLAT] Child sets migrated folio entire_mapcount=1, parent sets
entire_mapcount=2 and we end up with an AnonExclusive folio with
entire_mapcount=2! Assert fires in __folio_add_anon_rmap():

VM_WARN_ON_FOLIO(folio_test_large(folio) &&
folio_entire_mapcount(folio) > 1 &&
PageAnonExclusive(cur_page), folio)

This patch fixes the issue by correctly referencing the softleaf entry
fields for writable, softdirty and uffd-wp in set_pmd_migration_entry().

It also only updates A/D flags if the entry is present as these are
otherwise not meaningful for a softleaf entry.

This patch also flips the if (!present) { ... } else { ... } logic in
set_pmd_migration_entry() so it is easier to understand, and adds some
comments to make things clearer.

I was able to bisect this to commit 775465fd26a3 ("lib/test_hmm: add zone
device private THP test infrastructure") which first exposes this bug as
it was the commit that permitted test_hmm to generate the test.

However commit 65edfda6f3f2 ("mm/rmap: extend rmap and migration support
device-private entries") is the commit that actually enabled this
behaviour.
Published: 2026-06-25
Score: 5.5 Medium
EPSS: < 1% Very Low
KEV: No
Impact: n/a
Action: n/a
AI Analysis

Impact

The flaw stems from incorrectly using the pmd_write() helper on a softleaf PMD entry during the migration path. In this situation, the helper misinterprets the soft‑dirty flag as a writable bit, causing the kernel to install a PMD entry that is marked writable when it should be read‑only. The resulting inconsistent rmap state leads to an improper flag handling issue, and in the described test scenario an assertion is triggered, evidencing memory corruption in the kernel's page mapping data structures.

Affected Systems

All Linux kernel releases that contain the buggy code path – specifically those that include commit 65edfda6f3f2 and have not been backpatched with the later fix commit 775465fd26a3 – are affected. This encompasses the upstream kernel versions listed in the CPE data, including the 7.1 release candidates up to rc7, as well as any distribution kernels released before the patch was applied.

Risk and Exploitability

The CVSS score of 5.5 indicates moderate severity, while the EPSS score of less than 1% denotes a low likelihood of exploitation. The flaw is not presently listed in the CISA KEV catalog, suggesting no known active exploitation. Attack conditions appear to require a locally privileged user who can trigger device‑private huge page migration, such as through the kernel’s test infrastructure or by allocating device‑private THPs and manipulating migration flags. No evidence indicates that remote exploitation is feasible without such local control. The overall risk remains moderate with a low probability of exploitation in typical environments.

Generated by OpenCVE AI on August 13, 2026 at 19:12 UTC.

Remediation

No vendor fix or workaround currently provided.

OpenCVE Recommended Actions

  • Upgrade the Linux kernel to a version that includes the fix introduced by commit 775465fd26a3 or later.
  • If an OS upgrade is not possible, manually apply the patch that corrects flag handling in set_pmd_migration_entry to the kernel source and rebuild the kernel.
  • If device‑private huge pages or memory migration features are not required for your workloads, disable or restrict their usage to eliminate the execution path that triggers the bug.

Generated by OpenCVE AI on August 13, 2026 at 19:12 UTC.

Tracking

Sign in to view the affected projects.

Advisories

No advisories yet.

History

Thu, 13 Aug 2026 15:30:00 +0000

Type Values Removed Values Added
Weaknesses CWE-284

Tue, 30 Jun 2026 00:45:00 +0000


Thu, 25 Jun 2026 11:00:00 +0000

Type Values Removed Values Added
Weaknesses CWE-284

Thu, 25 Jun 2026 09:15:00 +0000

Type Values Removed Values Added
Description In the Linux kernel, the following vulnerability has been resolved: mm/huge_memory: use correct flags for device private PMD entry Commit 65edfda6f3f2 ("mm/rmap: extend rmap and migration support device-private entries") updated set_pmd_migration_entry() to use pmdp_huge_get_and_clear() in the softleaf case, but made no further adjustments to the function itself. Therefore this function continues to incorrectly use pmd_write(), pmd_soft_dirty() and pmd_uffd_wp() to determine whether the installed migration entry should be marked writable, softdirty or uffd-wp respectively. Whilst all are incorrect, the most problematic of these is pmd_write(), as this can lead to corrupted rmap state. On x86-64 _PAGE_SWP_SOFT_DIRTY is aliased to _PAGE_RW. So calling pmd_write() on a softleaf will return the softdirty state encoded in the entry, assuming CONFIG_MEM_SOFT_DIRTY was enabled. This was observed when running the hmm.hmm_device_private.anon_write_child selftest: 1. The test faults in a range then migrates it such that a device-private THP range is established. 2. The parent then migrates it to a device-private writable PMD entry whose folio is entirely AnonExclusive with entire_mapcount=1, softdirty set (accidentally correct write state). 3. The parent forks and the PMD entries are set to device-private read only entries, entire_mapcount=2, softdirty still set. 4. [BUG] The child writes to the range then migrates to RAM - intending to install non-writable migration entries - but replacing parent and child PMD mappings with WRITABLE entries due to misinterpreting the softdirty bit. 5. In remove_migration_pmd(), if !softleaf_is_migration_read(entry) we set the RMAP_EXCLUSIVE flag when calling folio_add_anon_rmap_pmd() for both parent and child, which are therefore AnonExclusive. 6. [SPLAT] Child sets migrated folio entire_mapcount=1, parent sets entire_mapcount=2 and we end up with an AnonExclusive folio with entire_mapcount=2! Assert fires in __folio_add_anon_rmap(): VM_WARN_ON_FOLIO(folio_test_large(folio) && folio_entire_mapcount(folio) > 1 && PageAnonExclusive(cur_page), folio) This patch fixes the issue by correctly referencing the softleaf entry fields for writable, softdirty and uffd-wp in set_pmd_migration_entry(). It also only updates A/D flags if the entry is present as these are otherwise not meaningful for a softleaf entry. This patch also flips the if (!present) { ... } else { ... } logic in set_pmd_migration_entry() so it is easier to understand, and adds some comments to make things clearer. I was able to bisect this to commit 775465fd26a3 ("lib/test_hmm: add zone device private THP test infrastructure") which first exposes this bug as it was the commit that permitted test_hmm to generate the test. However commit 65edfda6f3f2 ("mm/rmap: extend rmap and migration support device-private entries") is the commit that actually enabled this behaviour.
Title mm/huge_memory: use correct flags for device private PMD entry
First Time appeared Linux
Linux linux Kernel
CPEs cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*
Vendors & Products Linux
Linux linux Kernel
References

Subscriptions

Linux Linux Kernel
cve-icon MITRE

Status: PUBLISHED

Assigner: Linux

Published:

Updated: 2026-06-25T08:38:38.828Z

Reserved: 2026-06-09T07:44:35.388Z

Link: CVE-2026-53155

cve-icon Vulnrichment

No data.

cve-icon NVD

Status : Analyzed

Published: 2026-06-25T09:16:32.877

Modified: 2026-07-07T20:10:10.803

Link: CVE-2026-53155

cve-icon Redhat

Severity :

Publid Date: 2026-06-25T00:00:00Z

Links: CVE-2026-53155 - Bugzilla

cve-icon OpenCVE Enrichment

Updated: 2026-08-13T19:15:03Z

Weaknesses