CVE-2026-53155: mm/huge_memory: use correct flags for device private PMD entry

Published Jun 25, 2026
·
Updated

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

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

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

Therefore this function continues to incorrectly use pmdwrite(), pmdsoftdirty() and pmduffdwp() 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 pmdwrite(), as this can lead to corrupted rmap state.

On x86-64 PAGESWPSOFTDIRTY is aliased to PAGERW. So calling pmdwrite() on a softleaf will return the softdirty state encoded in the entry, assuming CONFIGMEMSOFTDIRTY was enabled.

This was observed when running the hmm.hmmdeviceprivate.anonwritechild 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 entiremapcount=1, softdirty set (accidentally correct write state).

3. The parent forks and the PMD entries are set to device-private read only entries, entiremapcount=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 removemigrationpmd(), if !softleafismigrationread(entry) we set the RMAPEXCLUSIVE flag when calling folioaddanonrmappmd() for both parent and child, which are therefore AnonExclusive.

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

VMWARNONFOLIO(foliotestlarge(folio) && folioentiremapcount(folio) > 1 && PageAnonExclusive(curpage), folio)

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

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 setpmdmigrationentry() so it is easier to understand, and adds some comments to make things clearer.

I was able to bisect this to commit 775465fd26a3 ("lib/testhmm: add zone device private THP test infrastructure") which first exposes this bug as it was the commit that permitted testhmm 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.

Affected Software

9 affected components
Linux Linux kernel
Linux Linux kernel>=6.19<7.0.13
Linux Linux kernel=7.1-rc1
Linux Linux kernel=7.1-rc2
Linux Linux kernel=7.1-rc3
Linux Linux kernel=7.1-rc4
Linux Linux kernel=7.1-rc5
Linux Linux kernel=7.1-rc6
Linux Linux kernel=7.1-rc7

Event History

Jun 25, 2026
CVE Published
via MITRE·08:38 AM
Data Sourced
via MITRE·08:38 AM
Description
Data Sourced
via NVD·09:16 AM
RemedyDescriptionSeverityAffected Software

Frequently Asked Questions

1

What is the severity of CVE-2026-53155?

The severity of CVE-2026-53155 is classified as risk level 42.

2

How do I fix CVE-2026-53155?

To fix CVE-2026-53155, update to the latest version of the Linux kernel where the vulnerability has been addressed.

3

What platforms are affected by CVE-2026-53155?

CVE-2026-53155 affects the Linux kernel across various platforms that utilize the huge memory feature.

4

What type of vulnerability is CVE-2026-53155?

CVE-2026-53155 is a memory management vulnerability related to device private PMD entries in the Linux kernel.

5

When was CVE-2026-53155 published?

CVE-2026-53155 was published on June 25, 2026.

Contact

SecAlerts Pty Ltd.
132 Wickham Terrace
Fortitude Valley,
QLD 4006, Australia
info@secalerts.co
By using SecAlerts services, you agree to our services end-user license agreement. This website is safeguarded by reCAPTCHA and governed by the Google Privacy Policy and Terms of Service. All names, logos, and brands of products are owned by their respective owners, and any usage of these names, logos, and brands for identification purposes only does not imply endorsement. If you possess any content that requires removal, please get in touch with us.
© 2026 SecAlerts Pty Ltd.
ABN: 70 645 966 203, ACN: 645 966 203