mm/pagewalk: fix stale walk->action escaping walk_pmd_range()

If ->pmd_entry() sets walk->action = ACTION_AGAIN, the pmd_none() check is retried. The PMD entry may be cleared at the point of retry.

In this case, if walk->ops->install_pte is not specified, the code continues to the next PMD entry in the range without resetting walk->action to ACTION_SUBTREE.

This leaves walk->action erroneously set to ACTION_AGAIN, which is incorrect.

This was incorrect but not problematic up until commit 3b89863c3fa4 ("mm/pagewalk: fix race between concurrent split and refault") which updated walk_pud_range() to check for walk->action == ACTION_AGAIN upon walk_pmd_range()'s return, causing the PUD walk to be retried.

In this case this results in duplicate walk callbacks being invoked, which is erroneous and will break any caller that is not idempotent with respect to this (and waste time for those which are).

A specific example of this breaking things is mincore which walks an internal cursor data structure a byte at a time on assumption that page table entry callbacks are called only once for each entry.

Fix the problem by resetting walk->action to ACTION_SUBTREE prior to the none check.

The pattern also exists in walk_pud_range() so fix it there too.

This issue was found through AI-based fuzzing.

Fixes 3b89863c3fa4 ("mm/pagewalk: fix race between concurrent split and refault")

Cc [email protected]

Assisted-by Claude:claude-opus-5

Signed-off-by Hyunwoo Kim <[email protected]>

---
 mm/pagewalk.c | 6 ++----
 1 file changed, 2 insertions(+), 4 deletions(-)

mm/pagewalk.c +2 -5

index 5d87c632a25507..d3bfece3193366 100644
@@ -126,6 +126,7 @@ static int walk_pmd_range(pud_t *pud, unsigned long addr, unsigned long end,
 	pmd = pmd_offset(pud, addr);
 	do {
 again:
+		walk->action = ACTION_SUBTREE;
 		next = pmd_addr_end(addr, end);
 		if (pmd_none(*pmd)) {
 			if (has_install)

@@ -138,8 +139,6 @@ static int walk_pmd_range(pud_t *pud, unsigned long addr, unsigned long end,
 				continue;
 		}
 
-		walk->action = ACTION_SUBTREE;
-
 		/*
 		 * This implies that each ->pmd_entry() handler
 		 * needs to know about pmd_trans_huge() pmds

@@ -196,6 +195,7 @@ static int walk_pud_range(p4d_t *p4d, unsigned long addr, unsigned long end,
 	pud = pud_offset(p4d, addr);
 	do {
  again:
+		walk->action = ACTION_SUBTREE;
 		next = pud_addr_end(addr, end);
 		if (pud_none(*pud)) {
 			if (has_install)

@@ -208,8 +208,6 @@ static int walk_pud_range(p4d_t *p4d, unsigned long addr, unsigned long end,
 				continue;
 		}
 
-		walk->action = ACTION_SUBTREE;
-
 		if (ops->pud_entry)
 			err = ops->pud_entry(pud, addr, next, walk);
 		if (err)
--

2.43.0

If ->pmd_entry() sets walk->action = ACTION_AGAIN, the pmd_none() check is retried. The PMD entry may be cleared at the point of retry.

In this case, if walk->ops->install_pte is not specified, the code continues to the next PMD entry in the range without resetting walk->action to ACTION_SUBTREE.

This leaves walk->action erroneously set to ACTION_AGAIN, which is incorrect.

This was incorrect but not problematic up until commit 3b89863c3fa4 ("mm/pagewalk: fix race between concurrent split and refault") which updated walk_pud_range() to check for walk->action == ACTION_AGAIN upon walk_pmd_range()'s return, causing the PUD walk to be retried.

In this case this results in duplicate walk callbacks being invoked, which is erroneous and will break any caller that is not idempotent with respect to this (and waste time for those which are).

A specific example of this breaking things is mincore which walks an internal cursor data structure a byte at a time on assumption that page table entry callbacks are called only once for each entry.

Fix the problem by resetting walk->action to ACTION_SUBTREE prior to the none check.

The pattern also exists in walk_pud_range() so fix it there too.

This issue was found through AI-based fuzzing.

Fixes 3b89863c3fa4 ("mm/pagewalk: fix race between concurrent split and refault")

Cc [email protected]

Assisted-by Claude:claude-opus-5

Signed-off-by Hyunwoo Kim <[email protected]>

---

If ->pmd_entry() sets walk->action = ACTION_AGAIN, the pmd_none() check is retried. The PMD entry may be cleared at the point of retry.

In this case, if walk->ops->install_pte is not specified, the code continues to the next PMD entry in the range without resetting walk->action to ACTION_SUBTREE.

This leaves walk->action erroneously set to ACTION_AGAIN, which is incorrect.

This was incorrect but not problematic up until commit 3b89863c3fa4 ("mm/pagewalk: fix race between concurrent split and refault") which updated walk_pud_range() to check for walk->action == ACTION_AGAIN upon walk_pmd_range()'s return, causing the PUD walk to be retried.

In this case this results in duplicate walk callbacks being invoked, which is erroneous and will break any caller that is not idempotent with respect to this (and waste time for those which are).

A specific example of this breaking things is mincore which walks an internal cursor data structure a byte at a time on assumption that page table entry callbacks are called only once for each entry.

Fix the problem by resetting walk->action to ACTION_SUBTREE prior to the none check.

The pattern also exists in walk_pud_range() so fix it there too.

This issue was found through AI-based fuzzing.

Fixes 3b89863c3fa4 ("mm/pagewalk: fix race between concurrent split and refault")

Cc [email protected]

 mm/pagewalk.c | 6 ++----
 1 file changed, 2 insertions(+), 4 deletions(-)

Quoted 16 lines · On Wed, 12 Aug 2026 01:18:57 +0900 Hyunwoo Kim <[email protected]> wrote:

If ->pmd_entry() sets walk->action = ACTION_AGAIN, the pmd_none() check is retried. The PMD entry may be cleared at the point of retry.

In this case, if walk->ops->install_pte is not specified, the code continues to the next PMD entry in the range without resetting walk->action to ACTION_SUBTREE.

This leaves walk->action erroneously set to ACTION_AGAIN, which is incorrect.

This was incorrect but not problematic up until commit 3b89863c3fa4 ("mm/pagewalk: fix race between concurrent split and refault") which updated walk_pud_range() to check for walk->action == ACTION_AGAIN upon walk_pmd_range()'s return, causing the PUD walk to be retried.

Quoted 4 lines

In this case this results in duplicate walk callbacks being invoked, which is erroneous and will break any caller that is not idempotent with respect to this (and waste time for those which are).

"break". Please describe the breakage completely. It's really the most important information in the whole effort.

IOW, when fixing a bug please describe the userspace-visible runtime effects of that bug.

eg, what were the results of the fuzzer?

Is there a Link:?

A stack trace?

Quoted 6 lines

A specific example of this breaking things is mincore which walks an internal cursor data structure a byte at a time on assumption that page table entry callbacks are called only once for each entry.

Quoted 8 lines

Fix the problem by resetting walk->action to ACTION_SUBTREE prior to the none check.

The pattern also exists in walk_pud_range() so fix it there too.

This issue was found through AI-based fuzzing.

Fixes 3b89863c3fa4 ("mm/pagewalk: fix race between concurrent split and refault")

It's good to cc the relevant Author(s).

Quoted 1 line

Cc [email protected]

We really should tell -stable maintainers (and all other users of earlier kernels) all about the above things.

Quoted 2 lines

 mm/pagewalk.c | 6 ++----
 1 file changed, 2 insertions(+), 4 deletions(-)

This depends on the above info, but I'd prefer to process the bugfix promptly and defer consideration of the selftest until the next -rc cycle.

Quoted 29 lines · Andrew Morton

Quoted 16 lines · On Wed, 12 Aug 2026 01:18:57 +0900 Hyunwoo Kim <[email protected]> wrote:

If ->pmd_entry() sets walk->action = ACTION_AGAIN, the pmd_none() check is retried. The PMD entry may be cleared at the point of retry.

In this case, if walk->ops->install_pte is not specified, the code continues to the next PMD entry in the range without resetting walk->action to ACTION_SUBTREE.

This leaves walk->action erroneously set to ACTION_AGAIN, which is incorrect.

This was incorrect but not problematic up until commit 3b89863c3fa4 ("mm/pagewalk: fix race between concurrent split and refault") which updated walk_pud_range() to check for walk->action == ACTION_AGAIN upon walk_pmd_range()'s return, causing the PUD walk to be retried.

Quoted 4 lines

In this case this results in duplicate walk callbacks being invoked, which is erroneous and will break any caller that is not idempotent with respect to this (and waste time for those which are).

"break". Please describe the breakage completely. It's really the most important information in the whole effort.

IOW, when fixing a bug please describe the userspace-visible runtime effects of that bug.

Quoted 1 line

eg, what were the results of the fuzzer?

To be precise, this is an out-of-bounds write.

Quoted 1 line

Is there a Link:?

This came from a local fuzzer, so there is no Link:

Quoted 2 lines

A stack trace?

...

Should I send a v3 with the changelog fixed? (in 24 hours, I guess?)

The added pagewalk_race_test maps two PMDs and faults in 2MB of the first one. A second thread then faults in the second PMD and drops it again with MADV_DONTNEED in a loop, while the main thread reads Rss for the mapping from /proc/self/smaps.

Clearing the second PMD while smaps_pte_range() runs leaves walk->action erroneously set to ACTION_AGAIN, which causes the PUD walk to be retried, so the first PMD is counted twice and Rss comes out twice as large as what was faulted in.

mincore() is the caller named in the fix, but the second walk writes past the length mincore() copies back, so it cannot be seen from userspace there. smaps reports what the callbacks counted, so the duplicate shows up in Rss.

A failure can only come from the kernel counting the same page twice, so missing the race is harmless. On an unfixed kernel the test fails after a few hundred reads at most and takes about half a second.

Assisted-by Claude:claude-opus-5

Signed-off-by Hyunwoo Kim <[email protected]>

---
 tools/testing/selftests/mm/.gitignore         |   1 +
 tools/testing/selftests/mm/Makefile           |   2 +
 tools/testing/selftests/mm/ksft_pagewalk.sh   |   4 +
 .../testing/selftests/mm/pagewalk_race_test.c | 138 ++++++++++++++++++
 tools/testing/selftests/mm/run_vmtests.sh     |   2 +
 tools/testing/selftests/mm/vm_util.h          |   1 +
 6 files changed, 148 insertions(+)
 create mode 100755 tools/testing/selftests/mm/ksft_pagewalk.sh
 create mode 100644 tools/testing/selftests/mm/pagewalk_race_test.c

tools/testing/selftests/mm/.gitignore +1 -0

index 9ccd9e1447e66b..92f981f97740fd 100644
@@ -66,3 +66,4 @@ merge
 prctl_thp_disable
 rmap
 folio_split_race_test
+pagewalk_race_test

tools/testing/selftests/mm/Makefile +2 -0

index e6df968f0971c8..cde9b22f121d4b 100644
@@ -105,6 +105,7 @@ TEST_GEN_FILES += guard-regions
 TEST_GEN_FILES += merge
 TEST_GEN_FILES += rmap
 TEST_GEN_FILES += folio_split_race_test
+TEST_GEN_FILES += pagewalk_race_test
 
 ifneq ($(ARCH),arm64)
 TEST_GEN_FILES += soft-dirty

@@ -163,6 +164,7 @@ TEST_PROGS += ksft_mlock.sh
 TEST_PROGS += ksft_mmap.sh
 TEST_PROGS += ksft_mremap.sh
 TEST_PROGS += ksft_pagemap.sh
+TEST_PROGS += ksft_pagewalk.sh
 TEST_PROGS += ksft_pfnmap.sh
 TEST_PROGS += ksft_pkey.sh
 TEST_PROGS += ksft_process_madv.sh

tools/testing/selftests/mm/ksft_pagewalk.sh new file +4 -0

new file mode 100755
index 00000000000000..6f6c3ee1c13ef4
@@ -0,0 +1,4 @@
+#!/bin/sh -e
+# SPDX-License-Identifier: GPL-2.0
+
+./run_vmtests.sh -t pagewalk

tools/testing/selftests/mm/pagewalk_race_test.c new file +20 -0

new file mode 100644
index 00000000000000..42fd6e75e821ed
@@ -0,0 +1,138 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Regression test for a stale walk->action escaping walk_pmd_range() and
+ * making walk_pud_range() walk the same range twice.
+ *
+ * The mapping is two PMDs inside one PUD. PMD 0 is populated once and left
+ * alone, PMD 1 is faulted in and dropped again by a second thread. Clearing
+ * PMD 1 under smaps_pte_range() makes it raise ACTION_AGAIN, and since it is
+ * the last entry the stale value leaves walk_pmd_range(), so smaps accounts
+ * PMD 0 twice. A kernel that does not reclaim the emptied page table never
+ * clears PMD 1 and so never hits the race.
+ *
+ * A hit can only come from the kernel counting the same page twice, so the
+ * test cannot fail spuriously.
+ */
+#define _GNU_SOURCE
+
+#include <pthread.h>
+#include <stdatomic.h>
+#include <stdio.h>

tools/testing/selftests/mm/pagewalk_race_test.c new file +32 -0

+		*pmd1 = 1;
+		madvise(pmd1, pmd_size, MADV_DONTNEED);
+	}
+	return NULL;
+}
+
+static unsigned long smaps_rss_kb(void)
+{
+	char buf[1024];
+	char *entry;
+
+	entry = __get_smap_entry(area, "Rss:", buf, sizeof(buf));
+	if (!entry)
+		ksft_exit_fail_msg("no Rss: entry for the test mapping\n");
+
+	return strtoul(entry, NULL, 10);
+}
+
+int main(void)
+{
+	unsigned long max_rss_kb, rss_kb = 0;
+	size_t size, pop_size, i;
+	pthread_t thread;
+	char *raw;
+
+	ksft_print_header();
+
+	pmd_size = read_pmd_pagesize();
+	if (!pmd_size)
+		ksft_exit_skip("Cannot determine PMD size\n");
+
+	if (sysconf(_SC_NPROCESSORS_ONLN) < 2)

tools/testing/selftests/mm/pagewalk_race_test.c new file +30 -0

+
+	pop_size = pmd_size < POP_MAX ? pmd_size : POP_MAX;
+	memset(area, 1, pop_size);
+
+	max_rss_kb = (pop_size >> 10) + 256;
+
+	/* Over the limit before racing means this is not our own mapping. */
+	rss_kb = smaps_rss_kb();
+	if (rss_kb > max_rss_kb)
+		ksft_exit_fail_msg("Rss is %lu kB before racing, expected at most %lu kB\n",
+				   rss_kb, max_rss_kb);
+
+	ksft_set_plan(1);
+	ksft_print_msg("racing smaps against MADV_DONTNEED, %d rounds\n",
+		       NR_ROUNDS);
+
+	if (pthread_create(&thread, NULL, racer, NULL))
+		ksft_exit_fail_msg("pthread_create failed\n");
+
+	for (i = 0; i < NR_ROUNDS; i++) {
+		rss_kb = smaps_rss_kb();
+		if (rss_kb > max_rss_kb)
+			break;
+	}
+
+	atomic_store_explicit(&stop, 1, memory_order_release);
+	pthread_join(thread, NULL);
+
+	if (i < NR_ROUNDS) {
+		ksft_print_msg("walk ran twice over the same range\n");

tools/testing/selftests/mm/run_vmtests.sh +2 -0

index 8c296dedf0474d..d90c6370814f7a 100755
@@ -398,6 +398,8 @@ fi
 
 CATEGORY="pagemap" run_test ./pagemap_ioctl
 
+CATEGORY="pagewalk" run_test ./pagewalk_race_test
+
 CATEGORY="pfnmap" run_test ./pfnmap
 
 # COW tests

tools/testing/selftests/mm/vm_util.h +1 -1

index ea8fc8fdf0eb0b..62292e2417d162 100644
@@ -88,6 +88,7 @@ bool pagemap_is_populated(int fd, char *start);
 unsigned long pagemap_get_pfn(int fd, char *start);
 void clear_softdirty(void);
 bool check_for_pattern(FILE *fp, const char *pattern, char *buf, size_t len);
+char *__get_smap_entry(void *addr, const char *pattern, char *buf, size_t len);
 uint64_t read_pmd_pagesize(void);
 unsigned long rss_anon(void);
 bool check_huge_anon(void *addr, int nr_hpages, uint64_t hpage_size);
--

2.43.0

The added pagewalk_race_test maps two PMDs and faults in 2MB of the first one. A second thread then faults in the second PMD and drops it again with MADV_DONTNEED in a loop, while the main thread reads Rss for the mapping from /proc/self/smaps.

Clearing the second PMD while smaps_pte_range() runs leaves walk->action erroneously set to ACTION_AGAIN, which causes the PUD walk to be retried, so the first PMD is counted twice and Rss comes out twice as large as what was faulted in.

mincore() is the caller named in the fix, but the second walk writes past the length mincore() copies back, so it cannot be seen from userspace there. smaps reports what the callbacks counted, so the duplicate shows up in Rss.

A failure can only come from the kernel counting the same page twice, so missing the race is harmless. On an unfixed kernel the test fails after a few hundred reads at most and takes about half a second.

Assisted-by Claude:claude-opus-5

Signed-off-by Hyunwoo Kim <[email protected]>

---

Quoted 19 lines · Hyunwoo Kim

The added pagewalk_race_test maps two PMDs and faults in 2MB of the first one. A second thread then faults in the second PMD and drops it again with MADV_DONTNEED in a loop, while the main thread reads Rss for the mapping from /proc/self/smaps.

Clearing the second PMD while smaps_pte_range() runs leaves walk->action erroneously set to ACTION_AGAIN, which causes the PUD walk to be retried, so the first PMD is counted twice and Rss comes out twice as large as what was faulted in.

mincore() is the caller named in the fix, but the second walk writes past the length mincore() copies back, so it cannot be seen from userspace there. smaps reports what the callbacks counted, so the duplicate shows up in Rss.

A failure can only come from the kernel counting the same page twice, so missing the race is harmless. On an unfixed kernel the test fails after a few hundred reads at most and takes about half a second.

Quoted 3 lines

Assisted-by Claude:claude-opus-5

Signed-off-by Hyunwoo Kim <[email protected]>

---

I'm sorry, but I don't consider such a specialized reproducer for a problem we hit once a good fit for a selftest.

Or am I missing something, that this here is more generic?

--
Cheers,

David

Quoted 20 lines · David Hildenbrand (Arm)

Quoted 19 lines · Hyunwoo Kim

The added pagewalk_race_test maps two PMDs and faults in 2MB of the first one. A second thread then faults in the second PMD and drops it again with MADV_DONTNEED in a loop, while the main thread reads Rss for the mapping from /proc/self/smaps.

Clearing the second PMD while smaps_pte_range() runs leaves walk->action erroneously set to ACTION_AGAIN, which causes the PUD walk to be retried, so the first PMD is counted twice and Rss comes out twice as large as what was faulted in.

mincore() is the caller named in the fix, but the second walk writes past the length mincore() copies back, so it cannot be seen from userspace there. smaps reports what the callbacks counted, so the duplicate shows up in Rss.

A failure can only come from the kernel counting the same page twice, so missing the race is harmless. On an unfixed kernel the test fails after a few hundred reads at most and takes about half a second.

Quoted 8 lines

Quoted 3 lines

Assisted-by Claude:claude-opus-5

Signed-off-by Hyunwoo Kim <[email protected]>

---

I'm sorry, but I don't consider such a specialized reproducer for a problem we hit once a good fit for a selftest.

Or am I missing something, that this here is more generic?

To be fair I did ask him for this. :)

I thought it would be useful to have a regression test because there's certainly no harm in it? The code is very sensitive and catching a similar mistake in future could be useful.

If you're sure this isn't valuable then he could just drop it, but it's my fault sorry Hyunwoo for giving you extra work in this case! My bad.

Quoted 36 lines · Lorenzo Stoakes (ARM)

Quoted 20 lines · David Hildenbrand (Arm)

Quoted 19 lines · Hyunwoo Kim

The added pagewalk_race_test maps two PMDs and faults in 2MB of the first one. A second thread then faults in the second PMD and drops it again with MADV_DONTNEED in a loop, while the main thread reads Rss for the mapping from /proc/self/smaps.

Clearing the second PMD while smaps_pte_range() runs leaves walk->action erroneously set to ACTION_AGAIN, which causes the PUD walk to be retried, so the first PMD is counted twice and Rss comes out twice as large as what was faulted in.

mincore() is the caller named in the fix, but the second walk writes past the length mincore() copies back, so it cannot be seen from userspace there. smaps reports what the callbacks counted, so the duplicate shows up in Rss.

A failure can only come from the kernel counting the same page twice, so missing the race is harmless. On an unfixed kernel the test fails after a few hundred reads at most and takes about half a second.

Quoted 8 lines

Quoted 3 lines

Assisted-by Claude:claude-opus-5

Signed-off-by Hyunwoo Kim <[email protected]>

---

I'm sorry, but I don't consider such a specialized reproducer for a problem we hit once a good fit for a selftest.

Or am I missing something, that this here is more generic?

To be fair I did ask him for this. :)

I thought it would be useful to have a regression test because there's certainly no harm in it? The code is very sensitive and catching a similar mistake in future could be useful.

Quoted 2 lines

If you're sure this isn't valuable then he could just drop it, but it's my fault sorry Hyunwoo for giving you extra work in this case! My bad.

pagewalk_race_test is just rather odd. If this would be part of a bigger test that covers more things than just one odd race, it might be better.

But we certainly don't want one new test file for each kernel bug we ever trigger, right? :)

--
Cheers,

David

Quoted 40 lines · David Hildenbrand (Arm)

Quoted 38 lines · Lorenzo Stoakes (ARM)

Quoted 20 lines · David Hildenbrand (Arm)

Quoted 19 lines · Hyunwoo Kim

The added pagewalk_race_test maps two PMDs and faults in 2MB of the first one. A second thread then faults in the second PMD and drops it again with MADV_DONTNEED in a loop, while the main thread reads Rss for the mapping from /proc/self/smaps.

Clearing the second PMD while smaps_pte_range() runs leaves walk->action erroneously set to ACTION_AGAIN, which causes the PUD walk to be retried, so the first PMD is counted twice and Rss comes out twice as large as what was faulted in.

mincore() is the caller named in the fix, but the second walk writes past the length mincore() copies back, so it cannot be seen from userspace there. smaps reports what the callbacks counted, so the duplicate shows up in Rss.

A failure can only come from the kernel counting the same page twice, so missing the race is harmless. On an unfixed kernel the test fails after a few hundred reads at most and takes about half a second.

Quoted 8 lines

Quoted 3 lines

Assisted-by Claude:claude-opus-5

Signed-off-by Hyunwoo Kim <[email protected]>

---

I'm sorry, but I don't consider such a specialized reproducer for a problem we hit once a good fit for a selftest.

Or am I missing something, that this here is more generic?

To be fair I did ask him for this. :)

I thought it would be useful to have a regression test because there's certainly no harm in it? The code is very sensitive and catching a similar mistake in future could be useful.

If you're sure this isn't valuable then he could just drop it, but it's my fault sorry Hyunwoo for giving you extra work in this case! My bad.

Quoted 5 lines

pagewalk_race_test is just rather odd. If this would be part of a bigger test that covers more things than just one odd race, it might be better.

But we certainly don't want one new test file for each kernel bug we ever trigger, right? :)

Right yeah :) sure we can drop this then. Sorry Hyunwoo!