Re: [PATCH 1/1] mm/huge_memory: fix pgtable withdrawal for huge zero PMDs

[Kiryl Shutsemau]

On Sun, Sep 13, 2026 at 03:23:12PM +0800, Lance Yang wrote:
> 
> On Sat, Sep 12, 2026 at 11:46:35PM -0700, Andrew Morton wrote:
> >On Sun, 13 Sep 2026 13:19:42 +0800 Lance Yang <lance.yang@xxxxxxxxx> wrote:
> >
> >> From: Lance Yang <lance.yang@xxxxxxxxx>
> >> 
> >> has_deposited_pgtable() uses !vma_is_dax() to decide whether a huge zero
> >> PMD has a deposited PTE page table. That also accepts raw PFN mappings
> >> of huge_zero_pfn, although vmf_insert_pfn_pmd() does not deposit a page
> >> table on x86.
> >> 
> >> Zapping such a mapping would call pgtable_trans_huge_withdraw() without
> >> a corresponding deposit. With pmd_huge_pte(mm, pmd) == NULL, that causes
> >> a NULL pointer dereference.
> >
> >That's the sort of thing we'd prefer to avoid.
> >
> >> Use vma_is_anonymous() for the huge zero PMD check. This matches how PTE
> >> page tables are allocated, deposited and moved.
> >> 
> >> - For anonymous page faults that install a huge zero PMD,
> >>   do_huge_pmd_anonymous_page() allocates a PTE page table and
> >>   set_huge_zero_folio() deposits it before installing the PMD.
> >> 
> >> - On fork, copy_huge_pmd() allocates and deposits a PTE page table when
> >>   copying a huge zero PMD into an anonymous VMA.
> >> 
> >> - Raw PFN mappings use vmf_insert_pfn_pmd(), and DAX file holes use
> >>   vmf_insert_folio_pmd() to map the huge zero folio. Both use insert_pmd(),
> >>   which deposits a PTE page table only when arch_needs_pgtable_deposit()
> >>   requires it.
> >> 
> >> - Moving an anonymous huge PMD preserves its deposited PTE page table.
> >>   move_huge_pmd() transfers the deposit when necessary. For UFFD MOVE,
> >>   both VMAs must be anonymous, and move_pages_huge_pmd() transfers the
> >>   deposit as well.
> >> 
> >> Keep arch_needs_pgtable_deposit() first so architectures that require a
> >> deposited PTE page table still return true regardless of the VMA type.
> >> 
> >> Commit d80a9cb1a64a ("mm/huge_memory: add and use
> >> normal_or_softleaf_folio_pmd()") removed the vma_is_special_huge() check
> >> in zap_huge_pmd(). That check skipped the huge zero PMD deposit test for
> >> non-DAX VM_PFNMAP and VM_MIXEDMAP mappings. Removing it exposed these
> >> mappings to the incorrect !vma_is_dax() test.
> >> 
> >> Fixes: d80a9cb1a64a ("mm/huge_memory: add and use normal_or_softleaf_folio_pmd()")
> >> Cc: stable@xxxxxxxxxxxxxxx
> >
> >How real is this?  Is there a reported-by:?  Do you have a reproducer? 
> 
> Yes, I reproduced it on x86 with a small test module. It sets
> VM_MIXEDMAP | VM_HUGEPAGE and calls vmf_insert_pfn_pmd() with
> huge_zero_pfn, without touching the page tables directly. A full-PMD
> munmap() crashes before the split series[1] as well.

Ah. So there's no real bug upstream, right?

And I am not sure it is how we want to address this. I don't think we
should allow randomly map huge zero page (and non-huge too). It can be a
security risk if it ever gets exposed writable.

See CVE-2015-3288 and 6b7339f4c31a ("mm: avoid setting up anonymous
pages into file mapping").

-- 
  Kiryl Shutsemau / Kirill A. Shutemov