CVE-2026-53155 in Linuxinfo

Summary

by MITRE • 06/25/2026

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.

VulDB is the best source for vulnerability data and more expert information about this specific topic.

Analysis

by VulDB Data Team • 06/25/2026

The vulnerability described involves a critical flaw in the Linux kernel's memory management subsystem, specifically within the huge memory handling mechanisms. This issue stems from incorrect flag usage when setting device-private PMD entries during memory migration operations, creating a scenario where rmap state becomes corrupted due to misinterpretation of memory entry attributes. The problem manifests in the set_pmd_migration_entry() function which fails to properly account for the distinct characteristics of softleaf entries compared to regular page table entries.

The technical root cause lies in how the kernel handles flags for device-private PMD entries during migration processes. The function continues to use pmd_write(), pmd_soft_dirty(), and pmd_uffd_wp() functions to determine whether installed migration entries should be marked as writable, softdirty, or uffd-wp respectively. This approach is fundamentally flawed because it incorrectly applies regular page table entry semantics to device-private softleaf entries where such flags have different meanings and interpretations. On x86-64 architectures, the _PAGE_SWP_SOFT_DIRTY flag being aliased to _PAGE_RW exacerbates this issue since calling pmd_write() on a softleaf returns the softdirty state rather than the actual write permission state.

The operational impact of this vulnerability is severe as demonstrated by the failing hmm.hmm_device_private.anon_write_child selftest case. During normal operation, when a parent process migrates memory to device-private writable PMD entries with specific folio states and then forks, the child process performs writes that should result in non-writable migration entries. However, due to the misinterpretation of the softdirty bit through pmd_write(), the system incorrectly installs writable entries instead, leading to corrupted rmap state tracking. This corruption occurs because remove_migration_pmd() function sets RMAP_EXCLUSIVE flags incorrectly, resulting in inconsistent mapcount values where a folio ends up with entire_mapcount=2 while being marked as AnonExclusive, triggering kernel assertions and potential system instability.

The vulnerability directly relates to CWE-125: Out-of-bounds Read and CWE-787: Out of Bounds Write in the context of memory management operations, representing a critical memory corruption issue within kernel space. From an ATT&CK perspective, this maps to T1059.003: Command and Scripting Interpreter - Kernel Module Execution and T1490: Inhibit System Recovery, as it could enable privilege escalation or system instability through improper memory management. The fix implemented addresses the core issue by correctly referencing softleaf entry fields for writable, softdirty, and uffd-wp attributes in set_pmd_migration_entry(), ensuring proper handling of A/D flags only when entries are present.

The mitigation strategy involves correcting the flag interpretation logic within the migration entry handling code to properly distinguish between regular page table entries and device-private softleaf entries. This requires updating the function to use appropriate accessors for softleaf-specific attributes rather than generic page table entry functions, eliminating the incorrect assumption that softdirty state can be interpreted through pmd_write() calls. Additionally, the patch restructures the conditional logic to improve code clarity and adds explanatory comments to prevent future regressions in this critical memory management path. The fix ensures that memory migration operations maintain proper rmap consistency while preventing the corruption that would otherwise occur during device-private entry handling scenarios.

This vulnerability demonstrates the complexity inherent in kernel memory management where subtle interactions between different subsystems can lead to catastrophic failures. The issue highlights the importance of careful flag handling in virtual memory systems and underscores the need for comprehensive testing of edge cases involving memory migration, device-private entries, and rmap state tracking. The bisection results showing commit 65edfda6f3f2 as the enabling commit emphasizes that this was not a pre-existing flaw but rather a consequence of extended functionality that did not properly account for all entry types in the migration path.

Responsible

Linux

Reservation

06/09/2026

Disclosure

06/25/2026

Moderation

accepted

CPE

ready

EPSS

0.00172

KEV

no

Activities

very low

Sources

Want to know what is going to be exploited?

We predict KEV entries!