Re: [PATCH v8 03/15] 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() corrupts migration and hwpoison entries by calling huge_pte_clear_uffd() on non-present swap entries.
--

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

mm: rename uffd-wp PTE accessors to uffd

Userfaultfd RWP will reuse the uffd-wp PTE bit to mark access-tracking PTEs.
This patch mechanically renames the internal uffd-wp accessors to uffd to 
reflect the broader usage, without introducing behavior changes.

> 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 does copy_hugetlb_page_range() corrupt
migration and hwpoison swap entries here?

The function calls huge_pte_clear_uffd() on non-present swap entries. This
applies the present PTE mask (e.g., _PAGE_UFFD) instead of the swap PTE mask
(_PAGE_SWP_UFFD). Because these bits reside at different positions (such as
bit 58 vs bit 3 on arm64, or bit 10 vs bit 2 on x86), applying the present
PTE mask to a swap entry inadvertently modifies other fields.

On arm64, this clears a bit inside the swap offset, which corrupts the
physical page frame number (PFN) stored in the migration entry. On x86, it
alters the swap type. When these corrupted swap entries are later faulted
in, the kernel may map the wrong physical page or panic.

This seems reachable if a process using userfaultfd WP forks while a hugetlb
page in the VMA is under migration or is hwpoisoned. The child VMA does not
inherit the WP flag, so the code attempts to clear the uffd bit on the swap
entries during the copy.

>  			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 is a pre-existing issue, but the exact same swap entry corruption
appears to happen here for migration entries as well.

>  			set_huge_pte_at(dst, addr, dst_pte, entry, sz);
>  		} else if (unlikely(pte_is_marker(entry))) {

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