Re: [PATCH v7 08/15] mm: handle VM_UFFD_RWP in khugepaged, rmap, and GUP

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:
- [High] Per-PTE VM_UFFD_RWP tracking state is silently destroyed upon page eviction, zap, or unmap for file-backed and shmem memory.
- [Medium] GUP with FOLL_FORCE on an inaccessible VM_UFFD_RWP VMA silently bypasses userfaultfd RWP tracking.
--

commit 92ff6bd1fb225e8b6307693d55c268c0ef54ee61
Author: Kiryl Shutsemau (Meta) <kas@kernel.org>

mm: handle VM_UFFD_RWP in khugepaged, rmap, and GUP

Three mm paths outside the fault handler gate on the uffd PTE bit
today: khugepaged (skip collapse on ranges carrying markers), rmap
(cap unmap batching), and GUP (force a fault through
gup_can_follow_protnone).

[ ... ]

> Extend each to treat VM_UFFD_RWP the same as VM_UFFD_WP; otherwise per-PTE
> RWP state is silently destroyed or bypassed.

[Severity: High]
Is the per-PTE VM_UFFD_RWP tracking state still silently destroyed upon page
eviction, zap, or unmap for file-backed and shmem memory?

When an RWP-protected file-backed page is unmapped due to memory pressure
in try_to_unmap_one() or via MADV_DONTNEED, the PTE is cleared to pte_none().

Because pte_install_uffd_wp_if_needed() and zap_install_uffd_wp_if_needed()
only check userfaultfd_wp(vma), no PTE marker is installed to remember the
RWP state:

include/linux/mm_inline.h:pte_install_uffd_wp_if_needed() {
	if (vma_is_anonymous(vma) || !userfaultfd_wp(vma))
		return false;
}

Additionally, UFFDIO_RWPROTECT explicitly skips pte_none() entries in
change_pte_range():

mm/mprotect.c:change_pte_range() {
	} else if (pte_none(oldpte)) {
		/*
		 * Nobody plays with any none ptes besides
		 * userfaultfd when applying the protections.
		 */
		if (likely(!uffd_wp))
			continue;
}

On subsequent access, the page faults in from the page cache with the default
vma->vm_page_prot (accessible), bypassing RWP tracking completely. Should
these functions also be updated to check for RWP?

> diff --git a/include/linux/mm.h b/include/linux/mm.h
> index 3d4d5f9a6f1bf..da8a07cd49a14 100644
> --- a/include/linux/mm.h
> +++ b/include/linux/mm.h

[ ... ]

> @@ -4644,11 +4644,25 @@ static inline int vm_fault_to_errno(vm_fault_t vm_fault, int foll_flags)
>  
>  /*
>   * Indicates whether GUP can follow a PROT_NONE mapped page, or whether
> - * a (NUMA hinting) fault is required.
> + * a (NUMA hinting or userfaultfd RWP) fault is required.
>   */
>  static inline bool gup_can_follow_protnone(const struct vm_area_struct *vma,
>  					   unsigned int flags)
>  {
> +	/*
> +	 * VM_UFFD_RWP uses protnone as an access-tracking marker, not for
> +	 * NUMA hinting. GUP must always take a fault so the access is
> +	 * delivered to userfaultfd, regardless of FOLL_HONOR_NUMA_FAULT.
> +	 *
> +	 * Only do so while the VMA is accessible. If it has been made
> +	 * inaccessible (e.g. mprotect(PROT_NONE)), fall through to the guard
> +	 * below: forcing a fault there would loop, as handle_mm_fault() makes
> +	 * no progress on protnone in an inaccessible VMA, and the access is
> +	 * denied regardless of RWP anyway.
> +	 */
> +	if (vma_test_single_mask(vma, VMA_UFFD_RWP) && vma_is_accessible(vma))
> +		return false;

[Severity: Medium]
Does this logic allow GUP with FOLL_FORCE to silently bypass userfaultfd
RWP tracking?

If an external process uses ptrace or process_vm_readv (which set FOLL_FORCE)
to access an RWP-protected VMA that has been marked inaccessible (for example
via mprotect(PROT_NONE)), vma_is_accessible() will return false.

This causes gup_can_follow_protnone() to return true, which instructs GUP
to proceed without triggering a fault, resulting in missed access
notifications for the VMM.

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