Re: [PATCH 06/10] mm/hugetlb: fix endless write fault on a leftover uffd bit

[Lorenzo Stoakes (ARM)]

On Thu, Oct 15, 2026 at 06:07:12PM +0200, David Hildenbrand (Arm) wrote:
> From: Josef Bacik <josef@xxxxxxxxxxxxxx>
>
> hugetlb_fault() resolves the uffd bit on a write fault only if the VMA is
> registered for userfaultfd write protection, and hugetlb_wp() bails out
> for any entry with the uffd bit set assuming hugetlb_fault() has already
> resolved it.
>
> When a read-only hugetlb entry with the uffd bit set is mapped in a VMA
> that is not registered for uffd-wp, a write fault to it never makes
> progress. If the access comes from the kernel, e.g. read(2) from
> /dev/zero into such page, the task spins in the page fault handler,
> ignores SIGKILL and keeps holding the locks taken by the system call.
>
> Such entries should not exist, but an unprivileged user can create them,
> for example with MADV_DONTNEED of a page protected with UFFDIO_RWPROTECT
> or with UFFDIO_COPY in MODE_WP racing with UFFDIO_UNREGISTER.

Ugh yuck. Uffd is another gift that keeps giving...

>
> Clear the uffd bit when the VMA is not registered for uffd-wp and let the
> fault proceed to hugetlb_wp(), like do_wp_page() does for regular pages.
>
> Note that a FOLL_FORCE write to a page protected with UFFDIO_RWPROTECT in
> a private VMA that was made PROT_NONE now drops the RWP protection of
> that page.
>
> Original fix generated by an LLM and sent in private by Josef.
>
> Fixes: 60d5b473d61b ("mm/hugetlb: fix uffd wr-protection for CoW optimization path")
> Reported-by: Chris Mason <mason@xxxxxxxxxx>
> Cc: stable@xxxxxxxxxxxxxxx
> Signed-off-by: Josef Bacik <josef@xxxxxxxxxxxxxx>
> [rppt: massage commit message]
> Signed-off-by: Mike Rapoport (Microsoft) <rppt@xxxxxxxxxx>
> [ david: convert comment into a TODO ]
> Signed-off-by: David Hildenbrand (Arm) <david@xxxxxxxxxx>

Looks sensible to me so:

Acked-by: Lorenzo Stoakes (ARM) <ljs@xxxxxxxxxx>

> ---
>  mm/hugetlb.c | 8 ++++++--
>  1 file changed, 6 insertions(+), 2 deletions(-)
>
> diff --git a/mm/hugetlb.c b/mm/hugetlb.c
> index f8ad2efd472cb..c3823f1958568 100644
> --- a/mm/hugetlb.c
> +++ b/mm/hugetlb.c
> @@ -6184,15 +6184,19 @@ vm_fault_t hugetlb_fault(struct mm_struct *mm, struct vm_area_struct *vma,
>  		goto out_ptl;
>
>  	/* Handle userfault-wp first, before trying to lock more pages */
> -	if (userfaultfd_wp(vma) && huge_pte_uffd(huge_ptep_get(mm, vmf.address, vmf.pte)) &&
> +	if (huge_pte_uffd(huge_ptep_get(mm, vmf.address, vmf.pte)) &&
>  	    (flags & FAULT_FLAG_WRITE) && !huge_pte_write(vmf.orig_pte)) {
> -		if (!userfaultfd_wp_async(vma)) {
> +		if (userfaultfd_wp(vma) && !userfaultfd_wp_async(vma)) {
>  			spin_unlock(vmf.ptl);
>  			hugetlb_vma_unlock_read(vma);
>  			mutex_unlock(&hugetlb_fault_mutex_table[hash]);
>  			return handle_userfault(&vmf, VM_UFFD_WP);
>  		}
>
> +		/*
> +		 * TODO: fix all cases where uffd PTE bits remain in VMAs that
> +		 * are no longer registered with uffd.
> +		 */
>  		vmf.orig_pte = huge_pte_clear_uffd(vmf.orig_pte);
>  		set_huge_pte_at(mm, vmf.address, vmf.pte, vmf.orig_pte,
>  				huge_page_size(hstate_vma(vma)));
>
> --
> 2.43.0
>

--
Cheers, Lorenzo