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 setpmdmigrationentry() to use pmdphugegetand_clear() in the softleaf case, but made no further adjustments to the function itself.
Therefore this function continues to incorrectly use pmdwrite(), pmdsoftdirty() and pmduffd_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 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:
The test faults in a range then migrates it such that a device-private THP range is established.
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).
The parent forks and the PMD entries are set to device-private read only entries, entire_mapcount=2, softdirty still set.
[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.
In removemigrationpmd(), if !softleafismigrationread(entry) we set the RMAPEXCLUSIVE flag when calling folioaddanonrmappmd() for both parent and child, which are therefore AnonExclusive.
[SPLAT] Child sets migrated folio entiremapcount=1, parent sets entiremapcount=2 and we end up with an AnonExclusive folio with entire_mapcount=2! Assert fires in _folioaddanonrmap():
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 setpmdmigration_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 setpmdmigration_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/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.
{
"cna_assigner": "Linux",
"osv_generated_from": "https://github.com/CVEProject/cvelistV5/tree/main/cves/2026/53xxx/CVE-2026-53155.json"
}