Re: [PATCH 2/4] mm: add vmf_insert_pfn_order() and vmf_pfn_order_ok() helpers

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found no new issues
in this patch, but noticed 1 related pre-existing issue it does not
introduce:
- [Critical] mm: missing cross-granularity zeropage checks in
  vmf_insert_pfn_prot() [1]
--

commit 4d09867f23905da16cf7a825dd8a13e152a14d1e
Author: Eliav Farber <farbere@amazon.com>

mm: add vmf_insert_pfn_order() and vmf_pfn_order_ok() helpers

This commit introduces vmf_pfn_order_ok() and vmf_insert_pfn_order() to
validate fault windows and PFN alignment and to dispatch PFN insertions
across PTE, PMD, and PUD orders for VM_PFNMAP fault handlers.

> diff --git a/mm/memory.c b/mm/memory.c
> index ab29ec719ae11..0c583442e0493 100644
> --- a/mm/memory.c
> +++ b/mm/memory.c
> @@ -3002,6 +3002,55 @@ vm_fault_t vmf_insert_pfn(struct vm_area_struct *vma, unsigned long addr,
>  }
>  EXPORT_SYMBOL(vmf_insert_pfn);
>  
> +/**
> + * vmf_insert_pfn_order - insert a pfn mapping of a given fault order
> + * @vmf: The fault being handled.
> + * @pfn: The pfn to map at the start of the order-aligned fault window.
> + * @order: The fault order (0 for a single page).
> + *
> + * Helper for ->fault and ->huge_fault handlers of VM_PFNMAP mappings: maps @pfn
> + * with a PTE for order 0, or with a PMD/PUD for PMD_ORDER/PUD_ORDER where the
> + * architecture supports huge PFN mappings. The caller must have checked the
> + * window and the pfn alignment with vmf_pfn_order_ok().
> + *
> + * vma cannot be a COW mapping.
> + *
> + * Return: vm_fault_t value; %VM_FAULT_FALLBACK if @order cannot be mapped, so
> + * that the fault is retried at a smaller order.
> + */
> +vm_fault_t vmf_insert_pfn_order(struct vm_fault *vmf, unsigned long pfn,
> +				unsigned int order)
> +{
> +	struct vm_area_struct *vma = vmf->vma;
> +	bool write = vmf->flags & FAULT_FLAG_WRITE;
> +
> +	if (!order)
> +		return vmf_insert_pfn(vma, vmf->address, pfn);
> +
> +	/*
> +	 * vmf_insert_pfn_pmd() refuses the huge zero folio's pfn with SIGBUS,
> +	 * while a PTE mapping of it is fine, so fall back to a smaller order.
> +	 */
> +	if (is_huge_zero_pfn(pfn))
> +		return VM_FAULT_FALLBACK;

[Severity: Critical]
This problem wasn't introduced by this patch, but can falling back to
order-0 here or dispatching to vmf_insert_pfn_pmd() and
vmf_insert_pfn_pud() below bypass zeropage checks across granularities
[1]?

Because is_huge_zero_pfn() and is_zero_pfn() match mutually exclusive PFNs,
when a huge zeropage PFN falls back to vmf_insert_pfn() ->
vmf_insert_pfn_prot() (or reaches vm_mixed_ok()), it only checks
is_zero_pfn(pfn), allowing the shared huge zeropage to be mapped writable
via PTEs and corrupted system-wide.  Conversely, vmf_insert_pfn_pmd() and
vmf_insert_pfn_pud() do not check is_zero_pfn(pfn) (and
vmf_insert_pfn_pud() does not check is_huge_zero_pfn(pfn) either), so
mapping the order-0 shared zeropage at PMD or PUD granularity exposes the
surrounding physical memory within that PMD/PUD range to userspace.

[1] https://sashiko.dev/#/bug/linux-c77c75ca-4c72-4dae-8d19-e971631bb97c

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20261111113045.35368-1-farbere@amazon.com?part=2