Re: [PATCH v9 10/15] mm/userfaultfd: add RWP fault delivery and expose UFFDIO_REGISTER_MODE_RWP

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [High] Infinite page fault loop (livelock) on hugetlb VMAs containing stale RWP or WP markers after UFFDIO_UNREGISTER.
--

commit 53f1ffbd6e1b1ae6560601d75e0a8a5ad93e1aa3
Author: Kiryl Shutsemau (Meta) <kas@kernel.org>

mm/userfaultfd: add RWP fault delivery and expose UFFDIO_REGISTER_MODE_RWP

This commit adds read-write protection (RWP) fault tracking to userfaultfd.
It introduces the UFFDIO_REGISTER_MODE_RWP flag and handles RWP faults at the
PTE, PMD, and hugetlb levels by delivering UFFD_PAGEFAULT_FLAG_RWP messages.

> diff --git a/mm/hugetlb.c b/mm/hugetlb.c
> index 4d0b6d7d9842f..f0ce2e9d4ba2d 100644
> --- a/mm/hugetlb.c
> +++ b/mm/hugetlb.c
> @@ -6063,6 +6063,17 @@ vm_fault_t hugetlb_fault(struct mm_struct *mm, struct vm_area_struct *vma,
>  		goto out_mutex;
>  	}
>  
> +	/*
> +	 * Protnone hugetlb PTEs with the uffd bit are used by
> +	 * userfaultfd RWP for access tracking. Plain PROT_NONE (without the
> +	 * marker) is not an RWP fault and is not expected on hugetlb (no
> +	 * NUMA hinting), so let normal hugetlb fault handling proceed.
> +	 */
> +	if (pte_protnone(vmf.orig_pte) && vma_is_accessible(vma) &&
> +	    userfaultfd_rwp(vma) && huge_pte_uffd(vmf.orig_pte)) {

[Severity: High]
Can this code cause an infinite page fault loop if the VMA is unregistered?

If an unprivileged user registers a hugetlb VMA with UFFDIO_REGISTER_MODE_RWP,
allows PTE markers to be placed, and then unregisters it via UFFDIO_UNREGISTER,
the PTE markers are not cleared. Subsequent memory accesses will trigger a page
fault, but since userfaultfd_rwp(vma) evaluates to false, this check is
bypassed.

For read faults, hugetlb_fault() falls through, marks the PROT_NONE PTE as
young, and returns 0 without restoring accessibility. Because the fault handler
continuously returns 0 without making the PTE accessible, the CPU retries the
instruction endlessly, resulting in a local denial of service.

This is a pre-existing issue for write faults via WP, but does this patch
introduce the same livelock for read faults via RWP? For WP, write faults skip
the UFFD_WP check and hugetlb_wp() catches the stale marker:

mm/hugetlb.c:hugetlb_wp() {
...
	if (!unshare && huge_pte_uffd(pte))
		return 0;
...
}

Because it returns 0 without upgrading the PTE to writable, the CPU retries
the instruction endlessly. Can a similar infinite loop occur here for RWP?

> +		return hugetlb_handle_userfault(&vmf, mapping, VM_UFFD_RWP);
> +	}
> +
>  	/*
>  	 * If we are going to COW/unshare the mapping later, we examine the
>  	 * pending reservations for this page now. This will ensure that any

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260706084805.8400-1-kirill@shutemov.name?part=10