Re: [PATCH v8 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 RWP tracking state is silently destroyed for file-backed memory during page eviction, page fault, and fork because the PTE marker infrastructure does not support VM_UFFD_RWP.
- [High] FOLL_FORCE accesses (e.g., via /proc/pid/mem) silently bypass userfaultfd RWP monitors on inaccessible VMAs due to an incorrect assumption in gup_can_follow_protnone().
--

commit a8febd9860609da477330a270aa0cc307fe15024
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.

> 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]
The commit message states the intention is to prevent per-PTE RWP state from
being silently destroyed or bypassed. Does this patch miss the PTE marker
infrastructure required for file-backed memory?

For example, during page eviction, try_to_unmap_one() relies on
pte_install_uffd_wp_if_needed(), but that function explicitly requires
userfaultfd_wp(vma):

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

This causes RWP VMAs to lose their tracking state entirely upon eviction.

Similarly, vmf_orig_pte_uffd_wp() in mm/memory.c ignores markers for RWP
VMAs during page faults, copy_pte_marker() drops markers during fork(),
and change_pte_range() in mm/mprotect.c skips unpopulated PTEs when
UFFDIO_RWPROTECT is called.

Are updates to the PTE marker infrastructure needed to fully support
VM_UFFD_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: High]
Does this logic allow FOLL_FORCE accesses to silently bypass the RWP
monitor?

The comment assumes access is denied regardless of RWP when the VMA is
inaccessible, but FOLL_FORCE (e.g., from ptrace or /proc/pid/mem)
explicitly bypasses VMA access permissions.

If an RWP VMA is made PROT_NONE, and FOLL_FORCE is used, this check
returns true because vma_is_accessible() is false. GUP will then follow
the PROT_NONE PTE and extract the page, bypassing the userfaultfd fault
path entirely.

> +
>  	/*
>  	 * If callers don't want to honor NUMA hinting faults, no need to
>  	 * determine if we would actually have to trigger a NUMA hinting fault.

[ ... ]

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