Re: [PATCH mm-hotfixes v3 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 attempts to fix a Use-After-Free race between vmap huge page promotion and ptdump by taking a read trylock on `init_mm.mmap_lock` before freeing page tables. However, the fix is incomplete. On x86 and arm64, ptdump can walk kernel page tables via `efi_mm` or `current->mm` (e.g., through `/sys/kernel/debug/page_tables/current_kernel`). In these cases, ptdump acquires the `mmap_write_lock` for the specific `mm` being walked, but does NOT acquire `init_mm.mmap_lock`. As a result, the trylock in `vmap_try_huge_pmd()` will succeed, and vmap will free the shared kernel page tables while ptdump is actively walking them, leaving the UAF unresolved.
--

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

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

This commit attempts to fix a Use-After-Free race between ptdump and vmap huge
page promotion by acquiring a read trylock on init_mm.mmap_lock before freeing
page tables.

Link: https://lore.kernel.org/linux-mm/20260706203128.162335-1-devnexen@gmail.com/
Closes: https://lore.kernel.org/all/6a287988.39669fcc.33b062.00a0.GAE@google.com/T/

> 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);
> +

[Severity: High]
This isn't a bug introduced by this patch, but does this assertion fully
protect shared kernel page tables during ptdump walks?

If ptdump walks kernel page tables via efi_mm or current->mm (for example,
through /sys/kernel/debug/page_tables/current_kernel), it locks the specific
mm being walked. This satisfies mmap_assert_write_locked(mm) in
walk_page_range_debug(), but it leaves init_mm unlocked.

>  	/* 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 is a pre-existing issue, but does locking only init_mm here completely
resolve the use-after-free?

Because ptdump can walk shared kernel page tables (above TASK_SIZE) using
efi_mm or current->mm, it will acquire the mmap_lock for that specific mm,
not init_mm. 

In that scenario, this trylock on init_mm.mmap_lock will succeed. This allows
vmap to free the PTE page while ptdump is actively reading it, leaving the
use-after-free unresolved for these specific debugfs paths.

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

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