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

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

[Lance Yang]

From: Lance Yang <lance.yang@linux.dev>

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.

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@vger.kernel.org
Signed-off-by: Lance Yang <lance.yang@linux.dev>
---
 mm/huge_memory.c | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/mm/huge_memory.c b/mm/huge_memory.c
index 6895b38e4704..0ed997a97416 100644
--- a/mm/huge_memory.c
+++ b/mm/huge_memory.c
@@ -2529,11 +2529,11 @@ static bool has_deposited_pgtable(struct vm_area_struct *vma, pmd_t pmdval,
 		return true;
 
 	/*
-	 * Huge zero always deposited except for DAX which handles itself, see
-	 * set_huge_zero_folio().
+	 * Huge zero PMDs have a deposited page table only for anonymous VMAs,
+	 * see set_huge_zero_folio().
 	 */
 	if (is_huge_zero_pmd(pmdval))
-		return !vma_is_dax(vma);
+		return vma_is_anonymous(vma);
 
 	/*
 	 * Otherwise, only anonymous folios are deposited, see
-- 
2.39.3 (Apple Git-146)

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

[Andrew Morton]

On Sun, 13 Sep 2026 13:19:42 +0800 Lance Yang <lance.yang@linux.dev> wrote:

> From: Lance Yang <lance.yang@linux.dev>
> 
> 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@vger.kernel.org

How real is this?  Is there a reported-by:?  Do you have a reproducer? 
Is it a theoretical, LLM-found-this thing which can't really happen?

> --- a/mm/huge_memory.c
> +++ b/mm/huge_memory.c
> @@ -2529,11 +2529,11 @@ static bool has_deposited_pgtable(struct vm_area_struct *vma, pmd_t pmdval,
>  		return true;
>  
>  	/*
> -	 * Huge zero always deposited except for DAX which handles itself, see
> -	 * set_huge_zero_folio().
> +	 * Huge zero PMDs have a deposited page table only for anonymous VMAs,
> +	 * see set_huge_zero_folio().
>  	 */
>  	if (is_huge_zero_pmd(pmdval))
> -		return !vma_is_dax(vma);
> +		return vma_is_anonymous(vma);
>  
>  	/*
>  	 * Otherwise, only anonymous folios are deposited, see

Thanks, I'll add it for test-n-review.

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

[Lance Yang]

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@linux.dev> wrote:
>
>> From: Lance Yang <lance.yang@linux.dev>
>> 
>> 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@vger.kernel.org
>
>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.

>Is it a theoretical, LLM-found-this thing which can't really happen?

I found this while reviewing the split series with LLM assistance.

mshv_vtl_low derives the PFN from the mmap offset, and its checks do not
exclude huge_zero_pfn. I haven't tested this on a Hyper-V, though.

[1] https://lore.kernel.org/linux-mm/cover.1787941780.git.yintirui@gmail.com/

>> --- a/mm/huge_memory.c
>> +++ b/mm/huge_memory.c
>> @@ -2529,11 +2529,11 @@ static bool has_deposited_pgtable(struct vm_area_struct *vma, pmd_t pmdval,
>>  		return true;
>>  
>>  	/*
>> -	 * Huge zero always deposited except for DAX which handles itself, see
>> -	 * set_huge_zero_folio().
>> +	 * Huge zero PMDs have a deposited page table only for anonymous VMAs,
>> +	 * see set_huge_zero_folio().
>>  	 */
>>  	if (is_huge_zero_pmd(pmdval))
>> -		return !vma_is_dax(vma);
>> +		return vma_is_anonymous(vma);
>>  
>>  	/*
>>  	 * Otherwise, only anonymous folios are deposited, see
>
>Thanks, I'll add it for test-n-review.

Thanks!

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@linux.dev> wrote:
> >
> >> From: Lance Yang <lance.yang@linux.dev>
> >> 
> >> 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@vger.kernel.org
> >
> >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

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

[David Hildenbrand (Arm)]

On 9/14/26 12:59, Kiryl Shutsemau wrote:
> 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:
>>>
>>>
>>> That's the sort of thing we'd prefer to avoid.
>>>
>>>
>>> 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?

Matches my understanding.

> 
> 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.

Due to some DAX stuff (and others) we have the shared zeropage in VM_MIXEDMAP.
And we have some elaborate checks in vm_mixed_zeropage_allowed() to test for that.

We should do a similar validation, and ideally just forbid it if not used yet.

-- 
Cheers,

David