PT-2026-52251 · Linux · Linux

Publicado

2026-06-25

·

Atualizado

2026-06-25

·

CVE-2026-53155

Nenhuma

Não há classificações de severidade ou métricas disponíveis. Quando houver, atualizaremos as informações correspondentes na página.
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.
Encontrou algum problema na descrição? Tem algo a acrescentar? Fique à vontade para nos escrever 👾

Identificadores relacionados

CVE-2026-53155

Produtos afetados

Linux