Re: [PATCH 1/2] mm/userfaultfd: recheck WP registration in the hugetlb UFFDIO_COPY retry

[Mike Rapoport]

Hi Jose,

On Thu, Oct 29, 2026 at 11:11:01PM +0100, Jose A. Perez de Azpillaga wrote:
> mfill_atomic_hugetlb() drops its locks to copy the source page with page
> faults enabled and then looks the VMA up again. The retry doesn't check
> that the VMA is still registered for WP, so if the range is re-registered
> without WP in that window, a UFFDIO_COPY_MODE_WP copy installs a uffd-wp
> PTE in a VMA without VM_UFFD_WP. That is one of the leftover uffd bits
> hugetlb_fault() has to tolerate.

The "leftover" sentence will be confusing for future readers
 
> The non-hugetlb retry goes through mfill_get_vma() again and fails with
> -EINVAL. Do the same check in the hugetlb retry.

No need to reference non-hugetlb path, just describe the added check.
 
> Fixes: 6041c6917903 ("mm/hugetlb: take care of UFFDIO_COPY_MODE_WP")
> Cc: stable@xxxxxxxxxxxxxxx
> Signed-off-by: Jose A. Perez de Azpillaga <azpijr@xxxxxxxxx>

With those fixed:

Reviewed-by: Mike Rapoport (Microsoft) <rppt@xxxxxxxxxx>

> ---
>  mm/userfaultfd.c | 4 ++++
>  1 file changed, 4 insertions(+)
> 
> diff --git a/mm/userfaultfd.c b/mm/userfaultfd.c
> index 3b71712edab4..a70ecfc8a998 100644
> --- a/mm/userfaultfd.c
> +++ b/mm/userfaultfd.c
> @@ -810,6 +810,10 @@ static __always_inline ssize_t mfill_atomic_hugetlb(
>  		if (vma_hpagesize != vma_kernel_pagesize(dst_vma))
>  			goto out_unlock_vma;
>  
> +		/* The range may have been re-registered without WP meanwhile. */
> +		if ((flags & MFILL_ATOMIC_WP) && !(dst_vma->vm_flags & VM_UFFD_WP))
> +			goto out_unlock_vma;
> +
>  		/*
>  		 * If memory mappings are changing because of non-cooperative
>  		 * operation (e.g. mremap) running in parallel, bail out and
> -- 
> 2.55.0
> 

-- 
Sincerely yours,
Mike.