[PATCH 0/2] mm/userfaultfd: recheck WP registration in the hugetlb UFFDIO_COPY retry

[PATCH 0/2] mm/userfaultfd: recheck WP registration in the hugetlb UFFDIO_COPY retry

[Jose A. Perez de Azpillaga]

The urgent fixes made hugetlb_fault() tolerate uffd bits left in VMAs
that are no longer registered for them, and asked for follow-ups that
remove the sources [1]. This is one: a hugetlb UFFDIO_COPY_MODE_WP copy
that has to fault in its source page doesn't recheck the WP registration
before retrying, so re-registering the range without WP in that window
leaves a uffd-wp PTE behind.

Patch 1 adds the check the non-hugetlb retry already gets from
mfill_get_vma(). Patch 2 adds a uffd-unit-tests case for it, which fails
on hugetlb without patch 1.

Question:

- The non-hugetlb retry compares the whole mfill_retry_state. hugetlb
  copies into a freshly allocated folio, so only WP seemed to matter
  there. Mike, would you rather have the full comparison on both paths?

The other source 6/10 of [1] mentions, UFFDIO_COPY in MODE_WP racing
with UFFDIO_UNREGISTER [2], is closed by "mm/userfaultfd: write-lock the
VMA before waking waiters when unregistering" [3].

Based on mm-unstable.

Tested on x86_64 in QEMU.

[1] https://lore.kernel.org/20261015-urgent_fixes-v1-0-42796911043b@kernel.org
[2] https://lore.kernel.org/20261015-urgent_fixes-v1-6-42796911043b@kernel.org
[3] https://lore.kernel.org/20261027-fixes_core-v1-23-6f74bec9a5bb@kernel.org (v1, now 23/47 in v2)

Jose A. Perez de Azpillaga (2):
  mm/userfaultfd: recheck WP registration in the hugetlb UFFDIO_COPY
    retry
  selftests/mm: add a uffd test for re-registering during UFFDIO_COPY

 mm/userfaultfd.c                             |   4 +
 tools/testing/selftests/mm/uffd-unit-tests.c | 105 +++++++++++++++++++
 2 files changed, 109 insertions(+)


base-commit: 24d45a1475dd4c671feb1df705f67ef2fc293969
-- 
2.55.0

[PATCH 1/2] mm/userfaultfd: recheck WP registration in the hugetlb UFFDIO_COPY retry

[Jose A. Perez de Azpillaga]

mfill_atomic_hugetlb() drops its locks to copy the source page with page
faults enabled and then looks the VMA up again. The retry doesn't check
that the VMA is still registered for WP, so if the range is re-registered
without WP in that window, a UFFDIO_COPY_MODE_WP copy installs a uffd-wp
PTE in a VMA without VM_UFFD_WP. That is one of the leftover uffd bits
hugetlb_fault() has to tolerate.

The non-hugetlb retry goes through mfill_get_vma() again and fails with
-EINVAL. Do the same check in the hugetlb retry.

Fixes: 6041c6917903 ("mm/hugetlb: take care of UFFDIO_COPY_MODE_WP")
Cc: stable@vger.kernel.org
Signed-off-by: Jose A. Perez de Azpillaga <azpijr@gmail.com>
---
 mm/userfaultfd.c | 4 ++++
 1 file changed, 4 insertions(+)

diff --git a/mm/userfaultfd.c b/mm/userfaultfd.c
index 3b71712edab4..a70ecfc8a998 100644
--- a/mm/userfaultfd.c
+++ b/mm/userfaultfd.c
@@ -810,6 +810,10 @@ static __always_inline ssize_t mfill_atomic_hugetlb(
 		if (vma_hpagesize != vma_kernel_pagesize(dst_vma))
 			goto out_unlock_vma;
 
+		/* The range may have been re-registered without WP meanwhile. */
+		if ((flags & MFILL_ATOMIC_WP) && !(dst_vma->vm_flags & VM_UFFD_WP))
+			goto out_unlock_vma;
+
 		/*
 		 * If memory mappings are changing because of non-cooperative
 		 * operation (e.g. mremap) running in parallel, bail out and
-- 
2.55.0

[PATCH 2/2] selftests/mm: add a uffd test for re-registering during UFFDIO_COPY

[Jose A. Perez de Azpillaga]

Re-register the destination without WP while a UFFDIO_COPY_MODE_WP copy
waits for its source page, then check that the copy fails with -EINVAL
and leaves no uffd-wp bit behind. This covers both the hugetlb and the
non-hugetlb UFFDIO_COPY retry.

Signed-off-by: Jose A. Perez de Azpillaga <azpijr@gmail.com>
---
 tools/testing/selftests/mm/uffd-unit-tests.c | 105 +++++++++++++++++++
 1 file changed, 105 insertions(+)

diff --git a/tools/testing/selftests/mm/uffd-unit-tests.c b/tools/testing/selftests/mm/uffd-unit-tests.c
index 2a97ba1d6feb..8a7efaa7b3ac 100644
--- a/tools/testing/selftests/mm/uffd-unit-tests.c
+++ b/tools/testing/selftests/mm/uffd-unit-tests.c
@@ -375,6 +375,104 @@ static void uffd_wp_unpopulated_test(uffd_global_test_opts_t *gopts, uffd_test_a
 	uffd_test_pass();
 }
 
+struct wp_copy_args {
+	uffd_global_test_opts_t *gopts;
+	char *src;
+	__s64 copy;
+};
+
+static void *wp_copy_thread(void *data)
+{
+	struct wp_copy_args *args = data;
+	struct uffdio_copy copy = {
+		.dst = (unsigned long)args->gopts->area_dst,
+		.src = (unsigned long)args->src,
+		.len = args->gopts->page_size,
+		.mode = UFFDIO_COPY_MODE_WP,
+	};
+
+	ioctl(args->gopts->uffd, UFFDIO_COPY, &copy);
+	args->copy = copy.copy;
+
+	return NULL;
+}
+
+/*
+ * UFFDIO_COPY drops its locks to fault in the source page.  Re-register the
+ * destination without WP while it waits there: the MODE_WP copy must then
+ * fail instead of leaving a uffd-wp bit in a VMA that no longer has WP.
+ */
+static void uffd_wp_copy_reregister_test(uffd_global_test_opts_t *gopts,
+					 uffd_test_args_t *args)
+{
+	struct uffdio_api api = { .api = UFFD_API };
+	struct wp_copy_args copy_args = { .gopts = gopts };
+	unsigned long len = gopts->page_size;
+	struct uffdio_zeropage zeropage;
+	struct uffd_msg msg;
+	struct pollfd pfd;
+	pthread_t thread;
+	uint64_t value;
+	int pagemap_fd;
+	int src_uffd;
+
+	/* The source fault comes from the kernel, so no UFFD_USER_MODE_ONLY */
+	src_uffd = uffd_open(O_CLOEXEC);
+	if (src_uffd < 0) {
+		uffd_test_skip("cannot open a kernel-mode userfaultfd");
+		return;
+	}
+	if (ioctl(src_uffd, UFFDIO_API, &api))
+		err("UFFDIO_API failed");
+
+	copy_args.src = mmap(NULL, len, PROT_READ | PROT_WRITE,
+			     MAP_PRIVATE | MAP_ANONYMOUS, -1, 0);
+	if (copy_args.src == MAP_FAILED)
+		err("mmap() failed");
+
+	if (uffd_register(src_uffd, copy_args.src, len, true, false, false))
+		err("register src failed");
+	if (uffd_register(gopts->uffd, gopts->area_dst, len, true, true, false))
+		err("register dst failed");
+
+	if (pthread_create(&thread, NULL, wp_copy_thread, &copy_args))
+		err("pthread_create() failed");
+
+	/* Wait until UFFDIO_COPY blocks on the source page */
+	pfd = (struct pollfd){ .fd = src_uffd, .events = POLLIN };
+	if (poll(&pfd, 1, 10000) != 1)
+		err("no fault on the source page");
+	if (read(src_uffd, &msg, sizeof(msg)) != sizeof(msg))
+		err("read() failed");
+
+	if (uffd_unregister(gopts->uffd, gopts->area_dst, len))
+		err("unregister dst failed");
+	if (uffd_register(gopts->uffd, gopts->area_dst, len, true, false, false))
+		err("re-register dst failed");
+
+	zeropage.range.start = (unsigned long)copy_args.src;
+	zeropage.range.len = len;
+	zeropage.mode = 0;
+	if (ioctl(src_uffd, UFFDIO_ZEROPAGE, &zeropage))
+		err("UFFDIO_ZEROPAGE failed");
+
+	if (pthread_join(thread, NULL))
+		err("pthread_join() failed");
+
+	if (copy_args.copy != -EINVAL)
+		err("UFFDIO_COPY returned %lld, expected %d",
+		    (long long)copy_args.copy, -EINVAL);
+
+	pagemap_fd = pagemap_open();
+	value = pagemap_get_entry(pagemap_fd, gopts->area_dst);
+	pagemap_check_wp(value, false);
+	close(pagemap_fd);
+
+	munmap(copy_args.src, len);
+	close(src_uffd);
+	uffd_test_pass();
+}
+
 static void uffd_wp_fork_test_common(uffd_global_test_opts_t *gopts, uffd_test_args_t *args,
 				     bool with_event)
 {
@@ -2403,6 +2501,13 @@ uffd_test_case_t uffd_tests[] = {
 		.uffd_feature_required =
 		UFFD_FEATURE_PAGEFAULT_FLAG_WP | UFFD_FEATURE_WP_UNPOPULATED,
 	},
+	{
+		.name = "wp-copy-reregister",
+		.uffd_fn = uffd_wp_copy_reregister_test,
+		.mem_targets = MEM_ALL,
+		.uffd_feature_required = UFFD_FEATURE_PAGEFAULT_FLAG_WP |
+		UFFD_FEATURE_WP_HUGETLBFS_SHMEM,
+	},
 	{
 		.name = "minor",
 		.uffd_fn = uffd_minor_test,
-- 
2.55.0

Re: [PATCH 0/2] mm/userfaultfd: recheck WP registration in the hugetlb UFFDIO_COPY retry

[Mike Rapoport]

Hi Jose,

On Thu, Oct 29, 2026 at 11:11:00PM +0100, Jose A. Perez de Azpillaga wrote:
> The urgent fixes made hugetlb_fault() tolerate uffd bits left in VMAs
> that are no longer registered for them, and asked for follow-ups that
> remove the sources [1]. This is one: a hugetlb UFFDIO_COPY_MODE_WP copy
> that has to fault in its source page doesn't recheck the WP registration
> before retrying, so re-registering the range without WP in that window
> leaves a uffd-wp PTE behind.
> 
> Patch 1 adds the check the non-hugetlb retry already gets from
> mfill_get_vma(). Patch 2 adds a uffd-unit-tests case for it, which fails
> on hugetlb without patch 1.
> 
> Question:
> 
> - The non-hugetlb retry compares the whole mfill_retry_state. hugetlb
>   copies into a freshly allocated folio, so only WP seemed to matter
>   there. Mike, would you rather have the full comparison on both paths?

Let's keep things simple and easily backportable :)

Since hugetlb does not leave a folio from the original VMA behind there's
no inconsistency we need to worry about.
 
> The other source 6/10 of [1] mentions, UFFDIO_COPY in MODE_WP racing
> with UFFDIO_UNREGISTER [2], is closed by "mm/userfaultfd: write-lock the
> VMA before waking waiters when unregistering" [3].
> 
> Based on mm-unstable.
> 
> Tested on x86_64 in QEMU.
> 
> [1] https://lore.kernel.org/20261015-urgent_fixes-v1-0-42796911043b@kernel.org
> [2] https://lore.kernel.org/20261015-urgent_fixes-v1-6-42796911043b@kernel.org
> [3] https://lore.kernel.org/20261027-fixes_core-v1-23-6f74bec9a5bb@kernel.org (v1, now 23/47 in v2)
> 
> Jose A. Perez de Azpillaga (2):
>   mm/userfaultfd: recheck WP registration in the hugetlb UFFDIO_COPY
>     retry
>   selftests/mm: add a uffd test for re-registering during UFFDIO_COPY
> 
>  mm/userfaultfd.c                             |   4 +
>  tools/testing/selftests/mm/uffd-unit-tests.c | 105 +++++++++++++++++++
>  2 files changed, 109 insertions(+)
> 
> 
> base-commit: 24d45a1475dd4c671feb1df705f67ef2fc293969
> -- 
> 2.55.0
> 

-- 
Sincerely yours,
Mike.

Re: [PATCH 1/2] mm/userfaultfd: recheck WP registration in the hugetlb UFFDIO_COPY retry

[Mike Rapoport]

Hi Jose,

On Thu, Oct 29, 2026 at 11:11:01PM +0100, Jose A. Perez de Azpillaga wrote:
> mfill_atomic_hugetlb() drops its locks to copy the source page with page
> faults enabled and then looks the VMA up again. The retry doesn't check
> that the VMA is still registered for WP, so if the range is re-registered
> without WP in that window, a UFFDIO_COPY_MODE_WP copy installs a uffd-wp
> PTE in a VMA without VM_UFFD_WP. That is one of the leftover uffd bits
> hugetlb_fault() has to tolerate.

The "leftover" sentence will be confusing for future readers
 
> The non-hugetlb retry goes through mfill_get_vma() again and fails with
> -EINVAL. Do the same check in the hugetlb retry.

No need to reference non-hugetlb path, just describe the added check.
 
> Fixes: 6041c6917903 ("mm/hugetlb: take care of UFFDIO_COPY_MODE_WP")
> Cc: stable@vger.kernel.org
> Signed-off-by: Jose A. Perez de Azpillaga <azpijr@gmail.com>

With those fixed:

Reviewed-by: Mike Rapoport (Microsoft) <rppt@kernel.org>

> ---
>  mm/userfaultfd.c | 4 ++++
>  1 file changed, 4 insertions(+)
> 
> diff --git a/mm/userfaultfd.c b/mm/userfaultfd.c
> index 3b71712edab4..a70ecfc8a998 100644
> --- a/mm/userfaultfd.c
> +++ b/mm/userfaultfd.c
> @@ -810,6 +810,10 @@ static __always_inline ssize_t mfill_atomic_hugetlb(
>  		if (vma_hpagesize != vma_kernel_pagesize(dst_vma))
>  			goto out_unlock_vma;
>  
> +		/* The range may have been re-registered without WP meanwhile. */
> +		if ((flags & MFILL_ATOMIC_WP) && !(dst_vma->vm_flags & VM_UFFD_WP))
> +			goto out_unlock_vma;
> +
>  		/*
>  		 * If memory mappings are changing because of non-cooperative
>  		 * operation (e.g. mremap) running in parallel, bail out and
> -- 
> 2.55.0
> 

-- 
Sincerely yours,
Mike.

Re: [PATCH 2/2] selftests/mm: add a uffd test for re-registering during UFFDIO_COPY

[Mike Rapoport]

On Thu, Oct 29, 2026 at 11:11:02PM +0100, Jose A. Perez de Azpillaga wrote:
> Re-register the destination without WP while a UFFDIO_COPY_MODE_WP copy
> waits for its source page, then check that the copy fails with -EINVAL
> and leaves no uffd-wp bit behind. This covers both the hugetlb and the
> non-hugetlb UFFDIO_COPY retry.

maybe "all memory types"?

> Signed-off-by: Jose A. Perez de Azpillaga <azpijr@gmail.com>
> ---
>  tools/testing/selftests/mm/uffd-unit-tests.c | 105 +++++++++++++++++++
>  1 file changed, 105 insertions(+)
> 
> diff --git a/tools/testing/selftests/mm/uffd-unit-tests.c b/tools/testing/selftests/mm/uffd-unit-tests.c
> index 2a97ba1d6feb..8a7efaa7b3ac 100644
> --- a/tools/testing/selftests/mm/uffd-unit-tests.c
> +++ b/tools/testing/selftests/mm/uffd-unit-tests.c
> @@ -375,6 +375,104 @@ static void uffd_wp_unpopulated_test(uffd_global_test_opts_t *gopts, uffd_test_a
>  	uffd_test_pass();
>  }
>  
> +struct wp_copy_args {
> +	uffd_global_test_opts_t *gopts;
> +	char *src;
> +	__s64 copy;

maybe result?

The rest looks Ok.

-- 
Sincerely yours,
Mike.

Re: [PATCH 1/2] mm/userfaultfd: recheck WP registration in the hugetlb UFFDIO_COPY retry

[Jose A. Perez de Azpillaga]

On 10/31/26 10:24 AM, Mike Rapoport wrote:
> Hi Jose,
> 
> On Thu, Oct 29, 2026 at 11:11:01PM +0100, Jose A. Perez de Azpillaga wrote:
>> mfill_atomic_hugetlb() drops its locks to copy the source page with page
>> faults enabled and then looks the VMA up again. The retry doesn't check
>> that the VMA is still registered for WP, so if the range is re-registered
>> without WP in that window, a UFFDIO_COPY_MODE_WP copy installs a uffd-wp
>> PTE in a VMA without VM_UFFD_WP. That is one of the leftover uffd bits
>> hugetlb_fault() has to tolerate.
> 
> The "leftover" sentence will be confusing for future readers

sure, will drop it.

>  
>> The non-hugetlb retry goes through mfill_get_vma() again and fails with
>> -EINVAL. Do the same check in the hugetlb retry.
> 
> No need to reference non-hugetlb path, just describe the added check.

okay, will do in v2.

>  
>> Fixes: 6041c6917903 ("mm/hugetlb: take care of UFFDIO_COPY_MODE_WP")
>> Cc: stable@vger.kernel.org
>> Signed-off-by: Jose A. Perez de Azpillaga <azpijr@gmail.com>
> 
> With those fixed:
> 
> Reviewed-by: Mike Rapoport (Microsoft) <rppt@kernel.org>

thanks for the review :)

> 
>> ---
>>  mm/userfaultfd.c | 4 ++++
>>  1 file changed, 4 insertions(+)
>>
>> diff --git a/mm/userfaultfd.c b/mm/userfaultfd.c
>> index 3b71712edab4..a70ecfc8a998 100644
>> --- a/mm/userfaultfd.c
>> +++ b/mm/userfaultfd.c
>> @@ -810,6 +810,10 @@ static __always_inline ssize_t mfill_atomic_hugetlb(
>>  		if (vma_hpagesize != vma_kernel_pagesize(dst_vma))
>>  			goto out_unlock_vma;
>>  
>> +		/* The range may have been re-registered without WP meanwhile. */
>> +		if ((flags & MFILL_ATOMIC_WP) && !(dst_vma->vm_flags & VM_UFFD_WP))
>> +			goto out_unlock_vma;
>> +
>>  		/*
>>  		 * If memory mappings are changing because of non-cooperative
>>  		 * operation (e.g. mremap) running in parallel, bail out and
>> -- 
>> 2.55.0
>>
> 


-- 
cheers,
jose a. p-a

Re: [PATCH 2/2] selftests/mm: add a uffd test for re-registering during UFFDIO_COPY

[Jose A. Perez de Azpillaga]

On 10/31/26 10:35 AM, Mike Rapoport wrote:
> On Thu, Oct 29, 2026 at 11:11:02PM +0100, Jose A. Perez de Azpillaga wrote:
>> Re-register the destination without WP while a UFFDIO_COPY_MODE_WP copy
>> waits for its source page, then check that the copy fails with -EINVAL
>> and leaves no uffd-wp bit behind. This covers both the hugetlb and the
>> non-hugetlb UFFDIO_COPY retry.
> 
> maybe "all memory types"?

yep, that reads better.

> 
>> Signed-off-by: Jose A. Perez de Azpillaga <azpijr@gmail.com>
>> ---
>>  tools/testing/selftests/mm/uffd-unit-tests.c | 105 +++++++++++++++++++
>>  1 file changed, 105 insertions(+)
>>
>> diff --git a/tools/testing/selftests/mm/uffd-unit-tests.c b/tools/testing/selftests/mm/uffd-unit-tests.c
>> index 2a97ba1d6feb..8a7efaa7b3ac 100644
>> --- a/tools/testing/selftests/mm/uffd-unit-tests.c
>> +++ b/tools/testing/selftests/mm/uffd-unit-tests.c
>> @@ -375,6 +375,104 @@ static void uffd_wp_unpopulated_test(uffd_global_test_opts_t *gopts, uffd_test_a
>>  	uffd_test_pass();
>>  }
>>  
>> +struct wp_copy_args {
>> +	uffd_global_test_opts_t *gopts;
>> +	char *src;
>> +	__s64 copy;
> 
> maybe result?

sure, will rename it in v2.

-- 
cheers,
jose a. p-a