Re: [PATCH v2 1/2] mm/pagewalk: fix stale walk->action escaping walk_pmd_range()

On Tue, Aug 11, 2026 at 12:37:02PM -0700, Andrew Morton wrote:
> 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.
> > 
> > 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?  

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

> Is there a Link:?  

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

> A stack trace?

[    2.272695] ==================================================================
[    2.273471] BUG: KASAN: slab-out-of-bounds in __mincore_unmapped_range+0x14f/0x190
[    2.274302] Write of size 1 at addr ffff888008d9b000 by task poc/106
[    2.274966]
[    2.275154] CPU: 0 UID: 1000 PID: 106 Comm: poc Not tainted 7.2.0-rc6-00429-ga7c7074b58d2 #55 PREEMPT(lazy)
[    2.275159] Hardware name: QEMU Ubuntu 24.04 PC v2 (i440FX + PIIX, arch_caps fix, 1996), BIOS 1.16.3-debian-1.16.3-2 04/01/2014
[    2.275164] Call Trace:
[    2.275170]  <TASK>
[    2.275172]  dump_stack_lvl+0x53/0x70
[    2.275200]  print_report+0xd0/0x630
[    2.275210]  ? __pfx__raw_spin_lock_irqsave+0x10/0x10
[    2.275219]  ? irqentry_exit+0xd2/0x670
[    2.275224]  ? irqentry_exit+0xd2/0x670
[    2.275226]  ? __virt_addr_valid+0xef/0x1a0
[    2.275239]  ? __mincore_unmapped_range+0x14f/0x190
[    2.275242]  kasan_report+0xce/0x100
[    2.275245]  ? __mincore_unmapped_range+0x14f/0x190
[    2.275248]  __mincore_unmapped_range+0x14f/0x190
[    2.275252]  mincore_unmapped_range+0x45/0x70
[    2.275254]  walk_pgd_range+0xafc/0xfc0
[    2.275261]  ? __pfx_walk_pgd_range+0x10/0x10
[    2.275264]  ? __update_load_avg_se+0x3d1/0x670
[    2.275275]  __walk_page_range+0xc0/0x310
[    2.275278]  ? __pfx_find_vma+0x10/0x10
[    2.275281]  ? finish_task_switch.isra.0+0x16d/0x4f0
[    2.275290]  walk_page_range_mm_unsafe+0x26f/0x3a0
[    2.275293]  ? __pfx_mtree_load+0x10/0x10
[    2.275298]  ? __pfx_walk_page_range_mm_unsafe+0x10/0x10
[    2.275302]  ? __free_frozen_pages+0x54d/0x7e0
[    2.275308]  __do_sys_mincore+0x132/0x380
[    2.275311]  do_syscall_64+0xf9/0x540
[    2.275316]  entry_SYSCALL_64_after_hwframe+0x77/0x7f
[    2.275322] RIP: 0033:0x422ccd
[    2.275326] Code: b3 66 2e 0f 1f 84 00 00 00 00 00 66 90 f3 0f 1e fa 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 c7 c1 b8 ff ff ff f7 d8 64 89 01 48
[    2.275329] RSP: 002b:00007fffffffec18 EFLAGS: 00000287 ORIG_RAX: 000000000000001b
[    2.275337] RAX: ffffffffffffffda RBX: 0000000000000066 RCX: 0000000000422ccd
[    2.275339] RDX: 00000000004d0940 RSI: 0000000001000000 RDI: 00007ffff4000000
[    2.275340] RBP: 00000000004d0940 R08: 0000000000000100 R09: 0000000000000100
[    2.275342] R10: 0000000000000100 R11: 0000000000000287 R12: 20c49ba5e353f7cf
[    2.275343] R13: 00000000004990d3 R14: 0000000000000000 R15: 0000000000000001
[    2.275346]  </TASK>
[    2.275347]
[    2.296904] The buggy address belongs to the object at ffff888008d9b000
[    2.296904]  which belongs to the cache sigqueue of size 80
[    2.298151] The buggy address is located 0 bytes inside of
[    2.298151]  allocated 80-byte region [ffff888008d9b000, ffff888008d9b050)
[    2.299408]
[    2.299601] The buggy address belongs to the physical page:
[    2.300191] page: refcount:0 mapcount:0 mapping:0000000000000000 index:0x0 pfn:0x8d9b
[    2.301001] flags: 0x100000000000000(node=0|zone=1)
[    2.301535] page_type: f5(slab)
[    2.301884] raw: 0100000000000000 ffff888107e46780 dead000000000122 0000000000000000
[    2.302687] raw: 0000000000000000 0000000800240024 00000000f5000000 0000000000000000
[    2.303489] page dumped because: kasan: bad access detected
[    2.304092]
[    2.304276] Memory state around the buggy address:
[    2.304801]  ffff888008d9af00: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
[    2.305567]  ffff888008d9af80: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
[    2.306340] >ffff888008d9b000: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
[    2.307115]                    ^
[    2.307474]  ffff888008d9b080: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
[    2.308237]  ffff888008d9b100: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
[    2.308997] ==================================================================

> 
> > 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")
> 
> It's good to cc the relevant Author(s).
> 
> > Cc: [email protected]
> 
> We really should tell -stable maintainers (and all other users of
> earlier kernels) all about the above things.
> 
> >  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.

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


Best regards,
Hyunwoo Kim