[PATCH 1/1] mm/huge_memory: disallow raw PMD mappings of the huge zero page

[PATCH 1/1] mm/huge_memory: disallow raw PMD mappings of the huge zero page

[Lance Yang]

vm_mixed_zeropage_allowed() validates zeropage insertion into
VM_MIXEDMAP VMAs. No in-tree user needs to insert the huge zero page
through vmf_insert_pfn_pmd().

Return VM_FAULT_SIGBUS if vmf_insert_pfn_pmd() is asked to map it.

Link: https://lore.kernel.org/linux-mm/f76beaf8-351a-4b22-b362-a945a5e1af6a@kernel.org/
Suggested-by: Kiryl Shutsemau <kas@kernel.org>
Suggested-by: David Hildenbrand <david@kernel.org>
Signed-off-by: Lance Yang <lance.yang@linux.dev>
---
 mm/huge_memory.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/mm/huge_memory.c b/mm/huge_memory.c
index bfd972b997f9..c02f21ce4f4c 100644
--- a/mm/huge_memory.c
+++ b/mm/huge_memory.c
@@ -1728,6 +1728,9 @@ vm_fault_t vmf_insert_pfn_pmd(struct vm_fault *vmf, unsigned long pfn,
 						(VM_PFNMAP|VM_MIXEDMAP));
 	BUG_ON((vma->vm_flags & VM_PFNMAP) && vma_is_cow_mapping(vma));
 
+	if (unlikely(is_huge_zero_pfn(pfn)))
+		return VM_FAULT_SIGBUS;
+
 	pfnmap_setup_cachemode_pfn(pfn, &pgprot);
 
 	return insert_pmd(vma, addr, vmf->pmd, fop, pgprot, write);
-- 
2.39.3 (Apple Git-146)

Re: [PATCH 1/1] mm/huge_memory: disallow raw PMD mappings of the huge zero page

[Kiryl Shutsemau]

On Thu, Sep 17, 2026 at 08:10:10PM +0800, Lance Yang wrote:
> vm_mixed_zeropage_allowed() validates zeropage insertion into
> VM_MIXEDMAP VMAs. No in-tree user needs to insert the huge zero page
> through vmf_insert_pfn_pmd().
> 
> Return VM_FAULT_SIGBUS if vmf_insert_pfn_pmd() is asked to map it.
> 
> Link: https://lore.kernel.org/linux-mm/f76beaf8-351a-4b22-b362-a945a5e1af6a@kernel.org/
> Suggested-by: Kiryl Shutsemau <kas@kernel.org>
> Suggested-by: David Hildenbrand <david@kernel.org>
> Signed-off-by: Lance Yang <lance.yang@linux.dev>

The patch looks fine, but don't we want to cover the same for non-huge
zero page in vmf_insert_pfn_prot()?

-- 
  Kiryl Shutsemau / Kirill A. Shutemov

Re: [PATCH 1/1] mm/huge_memory: disallow raw PMD mappings of the huge zero page

[David Hildenbrand (Arm)]

On 9/17/26 16:32, Kiryl Shutsemau wrote:
> On Thu, Sep 17, 2026 at 08:10:10PM +0800, Lance Yang wrote:
>> vm_mixed_zeropage_allowed() validates zeropage insertion into
>> VM_MIXEDMAP VMAs. No in-tree user needs to insert the huge zero page
>> through vmf_insert_pfn_pmd().
>>
>> Return VM_FAULT_SIGBUS if vmf_insert_pfn_pmd() is asked to map it.
>>
>> Link: https://lore.kernel.org/linux-mm/f76beaf8-351a-4b22-b362-a945a5e1af6a@kernel.org/
>> Suggested-by: Kiryl Shutsemau <kas@kernel.org>
>> Suggested-by: David Hildenbrand <david@kernel.org>
>> Signed-off-by: Lance Yang <lance.yang@linux.dev>
> 
> The patch looks fine, but don't we want to cover the same for non-huge
> zero page in vmf_insert_pfn_prot()?

Why would the zeropage be a problem in PFNMAP mapping?

-- 
Cheers,

David

Re: [PATCH 1/1] mm/huge_memory: disallow raw PMD mappings of the huge zero page

[David Hildenbrand (Arm)]

On 9/17/26 14:10, Lance Yang wrote:
> vm_mixed_zeropage_allowed() validates zeropage insertion into
> VM_MIXEDMAP VMAs. No in-tree user needs to insert the huge zero page
> through vmf_insert_pfn_pmd().

I think we want a clear description why we would want to forbid it. Is it
related to vm_mixed_ok/vm_mixed_zeropage_allowed?

Once again I am confused about which interfaces are actually valid for
VM_MIXEDMAP.>
> Return VM_FAULT_SIGBUS if vmf_insert_pfn_pmd() is asked to map it.
> 
> Link: https://lore.kernel.org/linux-mm/f76beaf8-351a-4b22-b362-a945a5e1af6a@kernel.org/
> Suggested-by: Kiryl Shutsemau <kas@kernel.org>
> Suggested-by: David Hildenbrand <david@kernel.org>
> Signed-off-by: Lance Yang <lance.yang@linux.dev>
> ---
>  mm/huge_memory.c | 3 +++
>  1 file changed, 3 insertions(+)
> 
> diff --git a/mm/huge_memory.c b/mm/huge_memory.c
> index bfd972b997f9..c02f21ce4f4c 100644
> --- a/mm/huge_memory.c
> +++ b/mm/huge_memory.c
> @@ -1728,6 +1728,9 @@ vm_fault_t vmf_insert_pfn_pmd(struct vm_fault *vmf, unsigned long pfn,
>  						(VM_PFNMAP|VM_MIXEDMAP));
>  	BUG_ON((vma->vm_flags & VM_PFNMAP) && vma_is_cow_mapping(vma));
>  
> +	if (unlikely(is_huge_zero_pfn(pfn)))
> +		return VM_FAULT_SIGBUS;
> +
>  	pfnmap_setup_cachemode_pfn(pfn, &pgprot);
>  
>  	return insert_pmd(vma, addr, vmf->pmd, fop, pgprot, write);

-- 
Cheers,

David

Re: [PATCH 1/1] mm/huge_memory: disallow raw PMD mappings of the huge zero page

[Kiryl Shutsemau]

On Thu, Sep 17, 2026 at 05:29:48PM +0200, David Hildenbrand (Arm) wrote:
> On 9/17/26 16:32, Kiryl Shutsemau wrote:
> > On Thu, Sep 17, 2026 at 08:10:10PM +0800, Lance Yang wrote:
> >> vm_mixed_zeropage_allowed() validates zeropage insertion into
> >> VM_MIXEDMAP VMAs. No in-tree user needs to insert the huge zero page
> >> through vmf_insert_pfn_pmd().
> >>
> >> Return VM_FAULT_SIGBUS if vmf_insert_pfn_pmd() is asked to map it.
> >>
> >> Link: https://lore.kernel.org/linux-mm/f76beaf8-351a-4b22-b362-a945a5e1af6a@kernel.org/
> >> Suggested-by: Kiryl Shutsemau <kas@kernel.org>
> >> Suggested-by: David Hildenbrand <david@kernel.org>
> >> Signed-off-by: Lance Yang <lance.yang@linux.dev>
> > 
> > The patch looks fine, but don't we want to cover the same for non-huge
> > zero page in vmf_insert_pfn_prot()?
> 
> Why would the zeropage be a problem in PFNMAP mapping?

Nothing enforces that it is read-only.

-- 
  Kiryl Shutsemau / Kirill A. Shutemov

Re: [PATCH 1/1] mm/huge_memory: disallow raw PMD mappings of the huge zero page

[Lance Yang]

On Thu, Sep 17, 2026 at 05:03:09PM +0100, Kiryl Shutsemau wrote:
>On Thu, Sep 17, 2026 at 05:29:48PM +0200, David Hildenbrand (Arm) wrote:
>> On 9/17/26 16:32, Kiryl Shutsemau wrote:
>> > On Thu, Sep 17, 2026 at 08:10:10PM +0800, Lance Yang wrote:
>> >> vm_mixed_zeropage_allowed() validates zeropage insertion into
>> >> VM_MIXEDMAP VMAs. No in-tree user needs to insert the huge zero page
>> >> through vmf_insert_pfn_pmd().
>> >>
>> >> Return VM_FAULT_SIGBUS if vmf_insert_pfn_pmd() is asked to map it.
>> >>
>> >> Link: https://lore.kernel.org/linux-mm/f76beaf8-351a-4b22-b362-a945a5e1af6a@kernel.org/
>> >> Suggested-by: Kiryl Shutsemau <kas@kernel.org>
>> >> Suggested-by: David Hildenbrand <david@kernel.org>
>> >> Signed-off-by: Lance Yang <lance.yang@linux.dev>
>> > 
>> > The patch looks fine, but don't we want to cover the same for non-huge
>> > zero page in vmf_insert_pfn_prot()?
>> 
>> Why would the zeropage be a problem in PFNMAP mapping?
>
>Nothing enforces that it is read-only.

No in-tree user inserts the zeropage through vmf_insert_pfn_prot(), so
rejecting it there should be fine.

Something like:

---8<---
The huge zeropage is reclaimable, but a raw PFN mapping does not pin it.
A PMD mapping of huge_zero_pfn can therefore outlive the folio.

No in-tree user needs either mapping, so reject both with VM_FAULT_SIGBUS
rather than risk making either shared zero page writable.

Link: https://lore.kernel.org/linux-mm/f76beaf8-351a-4b22-b362-a945a5e1af6a@kernel.org/
Suggested-by: Kiryl Shutsemau <kas@kernel.org>
Suggested-by: David Hildenbrand <david@kernel.org>
Signed-off-by: Lance Yang <lance.yang@linux.dev>
---

 mm/huge_memory.c | 3 +++
 mm/memory.c      | 3 +++
 2 files changed, 6 insertions(+)

diff --git a/mm/huge_memory.c b/mm/huge_memory.c
index b49bffe36d22..de34d64aa763 100644
--- a/mm/huge_memory.c
+++ b/mm/huge_memory.c
@@ -1723,6 +1723,9 @@ vm_fault_t vmf_insert_pfn_pmd(struct vm_fault *vmf, unsigned long pfn,
 						(VM_PFNMAP|VM_MIXEDMAP));
 	BUG_ON((vma->vm_flags & VM_PFNMAP) && vma_is_cow_mapping(vma));

+	if (unlikely(is_huge_zero_pfn(pfn)))
+		return VM_FAULT_SIGBUS;
+
 	pfnmap_setup_cachemode_pfn(pfn, &pgprot);

 	return insert_pmd(vma, addr, vmf->pmd, fop, pgprot, write);
diff --git a/mm/memory.c b/mm/memory.c
index 9e4a70421a6b..5d2d73c69fed 100644
--- a/mm/memory.c
+++ b/mm/memory.c
@@ -2956,6 +2956,9 @@ vm_fault_t vmf_insert_pfn_prot(struct vm_area_struct *vma, unsigned long addr,
 	BUG_ON((vma->vm_flags & VM_PFNMAP) && vma_is_cow_mapping(vma));
 	BUG_ON((vma->vm_flags & VM_MIXEDMAP) && pfn_valid(pfn));

+	if (unlikely(is_zero_pfn(pfn)))
+		return VM_FAULT_SIGBUS;
+
 	if (addr < vma->vm_start || addr >= vma->vm_end)
 		return VM_FAULT_SIGBUS;

--

That would keep both zeropages out of writable raw-PFN fault mappings ...
wdyt?

Cheers, Lance

Re: [PATCH 1/1] mm/huge_memory: disallow raw PMD mappings of the huge zero page

[Kiryl Shutsemau]

On Fri, Sep 18, 2026 at 10:52:14AM +0800, Lance Yang wrote:
> 
> On Thu, Sep 17, 2026 at 05:03:09PM +0100, Kiryl Shutsemau wrote:
> >On Thu, Sep 17, 2026 at 05:29:48PM +0200, David Hildenbrand (Arm) wrote:
> >> On 9/17/26 16:32, Kiryl Shutsemau wrote:
> >> > On Thu, Sep 17, 2026 at 08:10:10PM +0800, Lance Yang wrote:
> >> >> vm_mixed_zeropage_allowed() validates zeropage insertion into
> >> >> VM_MIXEDMAP VMAs. No in-tree user needs to insert the huge zero page
> >> >> through vmf_insert_pfn_pmd().
> >> >>
> >> >> Return VM_FAULT_SIGBUS if vmf_insert_pfn_pmd() is asked to map it.
> >> >>
> >> >> Link: https://lore.kernel.org/linux-mm/f76beaf8-351a-4b22-b362-a945a5e1af6a@kernel.org/
> >> >> Suggested-by: Kiryl Shutsemau <kas@kernel.org>
> >> >> Suggested-by: David Hildenbrand <david@kernel.org>
> >> >> Signed-off-by: Lance Yang <lance.yang@linux.dev>
> >> > 
> >> > The patch looks fine, but don't we want to cover the same for non-huge
> >> > zero page in vmf_insert_pfn_prot()?
> >> 
> >> Why would the zeropage be a problem in PFNMAP mapping?
> >
> >Nothing enforces that it is read-only.
> 
> No in-tree user inserts the zeropage through vmf_insert_pfn_prot(), so
> rejecting it there should be fine.
> 
> Something like:
> 
> ---8<---
> The huge zeropage is reclaimable, but a raw PFN mapping does not pin it.
> A PMD mapping of huge_zero_pfn can therefore outlive the folio.
> 
> No in-tree user needs either mapping, so reject both with VM_FAULT_SIGBUS
> rather than risk making either shared zero page writable.
> 
> Link: https://lore.kernel.org/linux-mm/f76beaf8-351a-4b22-b362-a945a5e1af6a@kernel.org/
> Suggested-by: Kiryl Shutsemau <kas@kernel.org>
> Suggested-by: David Hildenbrand <david@kernel.org>
> Signed-off-by: Lance Yang <lance.yang@linux.dev>

Reviewed-by: Kiryl Shutsemau (Meta) <kas@kernel.org>

-- 
  Kiryl Shutsemau / Kirill A. Shutemov