Re: [PATCH mm-hotfixes v4 3/4] mm/ptdump: always stabilise against page table freeing using init_mm

[sashiko-bot@kernel.org]

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

Pre-existing issues:
- [High] ptdump_walk_pgd() accesses user page tables under mmap_write_lock without draining per-VMA lock holders, allowing concurrent page table freeing to cause a use-after-free.
--

--- Patch [3]: [PATCH mm-hotfixes v4 3/4] mm/ptdump: always stabilise against page table freeing using init_mm ---
commit 75b68a063760f9b11fe2b9d0fa97f5e54d15f043
Author: Lorenzo Stoakes (ARM) <ljs@kernel.org>
Subject: mm/ptdump: always stabilise against page table freeing using init_mm

This commit fixes races between ptdump and kernel page table freeing by
acquiring a nested mmap write lock for init_mm in ptdump_walk_pgd().
It also adds corresponding assertions to walk_page_range_debug().

> diff --git a/mm/ptdump.c b/mm/ptdump.c
> index 973020000096c..5851096e6f656 100644
> --- a/mm/ptdump.c
> +++ b/mm/ptdump.c
> @@ -178,11 +178,18 @@ void ptdump_walk_pgd(struct ptdump_state *st, struct mm_struct *mm, pgd_t *pgd)
>  
>  	get_online_mems();
>  	mmap_write_lock(mm);
> +	/* To stabilise kernel page tables we must hold the init_mm lock too. */
> +	if (mm != &init_mm)
> +		mmap_write_lock_nested(&init_mm, SINGLE_DEPTH_NESTING);
> +

[Severity: High]
This isn't a bug introduced by this patch, but does this code leave us
vulnerable to a race with per-VMA lock holders?

The mmap_write_lock() alone doesn't exclude threads already holding a
per-VMA lock. Only vma_start_write() drains them. If a concurrent thread
runs a VMA-locked operation like MADV_DONTNEED, it can clear PMDs and free
PTE pages via PT_RECLAIM while this walk is happening.

Because walk_page_range_debug() configures the walk with no_vma = true,
it bypasses VMA lookup entirely:

mm/pagewalk.c:walk_page_range_debug() {
	struct mm_walk walk = {
		.ops		= ops,
		.mm		= mm,
		.pgd		= pgd,
		.private	= private,
		.no_vma		= true
	};

This means we never get a synchronization point to exclude per-VMA
operations. Could this lead to a use-after-free while walking arbitrary
user page tables?

>  	while (range->start != range->end) {
>  		walk_page_range_debug(mm, range->start, range->end,
>  				      &ptdump_ops, pgd, st);
>  		range++;
>  	}

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260716-series-vmap-race-fix-v4-0-8c108c4317df@kernel.org?part=3