Re: [PATCH v5 07/18] mm: rename uffd-wp PTE accessors to uffd

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:

Pre-existing issues:
- [Critical] copy_hugetlb_page_range() incorrectly applies huge_pte_clear_uffd() to non-present swap entries (HWPoison and Migration entries), which fails to clear the intended bit and can corrupt the swap entry's offset.
--

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

mm: rename uffd-wp PTE accessors to uffd

This commit mechanically renames uffd-wp PTE accessors, capability queries,
and scan enums to drop the -wp suffix. This prepares the codebase for
userfaultfd RWP to reuse the same PTE bit for access tracking.

> diff --git a/mm/hugetlb.c b/mm/hugetlb.c
> index 571212b80835e..d0c81a056ae2a 100644
> --- a/mm/hugetlb.c
> +++ b/mm/hugetlb.c
> @@ -4918,10 +4918,10 @@ int copy_hugetlb_page_range(struct mm_struct *dst, struct mm_struct *src,
>  		softleaf = softleaf_from_pte(entry);
>  		if (unlikely(softleaf_is_hwpoison(softleaf))) {
>  			if (!userfaultfd_wp(dst_vma))
> -				entry = huge_pte_clear_uffd_wp(entry);
> +				entry = huge_pte_clear_uffd(entry);

[Severity: Critical]
This is a pre-existing issue, but doesn't this incorrectly apply the
present-PTE clear function to a non-present swap entry?

For non-present entries like hwpoison or migration entries, shouldn't we use
pte_swp_clear_uffd() instead of huge_pte_clear_uffd()? 

Since huge_pte_clear_uffd() targets the present-PTE bit index, which on
architectures like arm64 is located at a different bit (e.g., bit 58) than
the swap PTE bit index (bit 3).

Migration entries store the page PFN in the swap offset. Could clearing the
wrong bit accidentally corrupt the PFN? When the migration completes, this
corrupted PFN could then be restored into the PTE.

>  			set_huge_pte_at(dst, addr, dst_pte, entry, sz);
>  		} else if (unlikely(softleaf_is_migration(softleaf))) {
> -			bool uffd_wp = pte_swp_uffd_wp(entry);
> +			bool uffd = pte_swp_uffd(entry);
>  
>  			if (!softleaf_is_migration_read(softleaf) && cow) {
>  				/*
> @@ -4931,12 +4931,12 @@ int copy_hugetlb_page_range(struct mm_struct *dst, struct mm_struct *src,
>  				softleaf = make_readable_migration_entry(
>  							swp_offset(softleaf));
>  				entry = swp_entry_to_pte(softleaf);
> -				if (userfaultfd_wp(src_vma) && uffd_wp)
> -					entry = pte_swp_mkuffd_wp(entry);
> +				if (userfaultfd_wp(src_vma) && uffd)
> +					entry = pte_swp_mkuffd(entry);
>  				set_huge_pte_at(src, addr, src_pte, entry, sz);
>  			}
>  			if (!userfaultfd_wp(dst_vma))
> -				entry = huge_pte_clear_uffd_wp(entry);
> +				entry = huge_pte_clear_uffd(entry);

[Severity: Critical]
This isn't a bug introduced by this patch, but this shares the same issue as
above. We are clearing the UFFD bit on a migration entry using
huge_pte_clear_uffd(). 

Is it possible to change this to pte_swp_clear_uffd() to avoid corrupting
the migration entry's PFN?

>  			set_huge_pte_at(dst, addr, dst_pte, entry, sz);

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