Re: [PATCH mm-hotfixes v2 1/4] mm/vmalloc: acquire init_mm lock on huge vmap to avoid ptdump UAF

[sashiko-bot@kernel.org]

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

Pre-existing issues:
- [High] The patch incompletely fixes a Use-After-Free race between vmap page table freeing and ptdump kernel page table walks. It fails to account for ptdump walking shared kernel page tables via user or EFI mm_structs.
--

--- Patch [1]: [PATCH mm-hotfixes v2 1/4] mm/vmalloc: acquire init_mm lock on huge vmap to avoid ptdump UAF ---
commit 3389cf765da1fbcf8e028033238bb065f9a3ca0e
Author: Lorenzo Stoakes <ljs@kernel.org>

mm/vmalloc: acquire init_mm lock on huge vmap to avoid ptdump UAF

This patch attempts to fix a use-after-free race between ptdump and vmap
by having vmap acquire the mmap read trylock on init_mm before freeing
page tables when promoting to huge pages. It also updates ptdump to assert
that the mmap write lock is held.

Link: https://lore.kernel.org/linux-mm/20260706203128.162335-1-devnexen@gmail.com/

> diff --git a/mm/pagewalk.c b/mm/pagewalk.c
> index 3ae2586ff45b4..bbcfd68d0907d 100644
> --- a/mm/pagewalk.c
> +++ b/mm/pagewalk.c

[ ... ]

> @@ -691,6 +693,16 @@ int walk_page_range_debug(struct mm_struct *mm, unsigned long start,
>  		.no_vma		= true
>  	};
>  
> +	/*
> +	 * When walking userland page tables, an mmap write lock must be held to
> +	 * account for munmap() downgrading to an mmap read lock when tearing
> +	 * down page tables.
> +	 *
> +	 * When walking kernel page tables, an mmap write lock must also be held
> +	 * to account for page table freeing on vmap huge page mapping.
> +	 */
> +	mmap_assert_write_locked(mm);
> +
>  	/* For convenience, we allow traversal of kernel mappings. */
>  	if (mm == &init_mm)
>  		return walk_kernel_page_table_range(start, end, ops,

> diff --git a/mm/vmalloc.c b/mm/vmalloc.c
> index 1afca3568b9b6..1fa9ac6e43d4f 100644
> --- a/mm/vmalloc.c
> +++ b/mm/vmalloc.c

[ ... ]

> @@ -158,10 +159,25 @@ static int vmap_try_huge_pmd(pmd_t *pmd, unsigned long addr, unsigned long end,
>  	if (!IS_ALIGNED(phys_addr, PMD_SIZE))
>  		return 0;
>  
> -	if (pmd_present(*pmd) && !pmd_free_pte_page(pmd, addr))
> -		return 0;
> +	if (!pmd_present(*pmd))
> +		return pmd_set_huge(pmd, phys_addr, prot);
>  
> -	return pmd_set_huge(pmd, phys_addr, prot);
> +	/*
> +	 * Kernel page table walkers either walk ranges they own exclusively or
> +	 * hold the mmap write lock on init_mm (ptdump being the motivating
> +	 * case).
> +	 *
> +	 * Therefore, acquire the mmap read lock to prevent use-after-free when
> +	 * freeing page tables.
> +	 */
> +#ifndef CONFIG_ARM64
> +	scoped_cond_guard(mmap_read_lock_try, return 0, &init_mm)
> +#endif

[Severity: High]
This isn't a bug introduced by this patch, but does this completely fix the
UAF for all ptdump walkers?

When ptdump is invoked on efi_mm or current->mm, it only locks the mmap_lock
of that specific mm_struct before walking the shared kernel page tables.

Since it doesn't hold init_mm.mmap_lock, the trylock here in vmap will
succeed, allowing vmap to free the page tables while ptdump is still
concurrently reading them.

For example, in mm/ptdump.c:ptdump_walk_pgd():

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

If this is called with efi_mm or current->mm, the lock on init_mm isn't held,
and the race remains. The newly added mmap_assert_write_locked(mm) in
walk_page_range_debug() will also pass for efi_mm or current->mm without
verifying that init_mm is locked.

Should ptdump also acquire init_mm's mmap_lock before walking shared kernel
page tables?

> +	{
> +		if (!pmd_free_pte_page(pmd, addr))
> +			return 0;
> +		return pmd_set_huge(pmd, phys_addr, prot);
> +	}
>  }

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260712-series-vmap-race-fix-v2-0-ad134cc3a12a@kernel.org?part=1