Re: [PATCH mm-hotfixes v6 1/5] 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 `mmap_read_trylock(&init_mm)` before freeing page tables in `vmap_try_huge_*()`. However, the fix is incomplete. The ptdump utility provides debugfs interfaces (e.g., `/sys/kernel/debug/page_tables/current_kernel` and `efi` on x86, or `efi_page_tables` on RISC-V) that walk the kernel address space using other `mm_struct`s like `current->mm` or `efi_mm`. During these walks, `ptdump_walk_pgd()` acquires the write lock on the provided `mm`, bypassing the `init_mm` lock completely. Because kernel page tables (PUDs/PMDs) are shared globally across all processes, ptdump traverses the exact same kernel page table pages that vmap operates on in `init_mm`. Since vmap attempts to read-lock `init_mm`, and ptdump write-locked `current->mm` (or `efi_mm`), there is no mutual exclusion. vmap will successfully acquire its lock and free the PTE/PMD pages while ptdump is concurrently dereferencing them.
--

--- Patch [1]: [PATCH mm-hotfixes v6 1/5] mm/vmalloc: acquire init_mm lock on huge vmap to avoid ptdump UAF ---
commit efa73ddb526da8e42ad98e0cfb9807d1f1de063d
Author: Lorenzo Stoakes (ARM) <ljs@kernel.org>

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

This commit attempts to fix a race condition between ptdump walking kernel 
page tables and vmap promoting them to huge pages. It introduces an mmap 
read lock on init_mm during page table freeing to prevent ptdump from 
accessing freed pages while walking.

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

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

[ ... ]

> @@ -158,10 +159,24 @@ 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);
> +	/*
> +	 * Acquire the mmap read lock to exclude ptdump, which walks
> +	 * kernel page tables it does not own under the mmap write lock.
> +	 *
> +	 * Concurrent read lock holders are safe: each exclusively owns
> +	 * the range it operates on and cannot reach this page table.
> +	 */
> +#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 init_mm here fully exclude
ptdump from walking and accessing these page tables?

The ptdump utility can walk the kernel address space using other mm_struct
contexts besides init_mm. For example, reading the current_kernel debugfs
file on x86 triggers a walk using current->mm:

arch/x86/mm/debug_pagetables.c:ptdump_curknl_show() {
    ...
    ptdump_walk_pgd_level_debugfs(m, current->mm, false);
}

This walk acquires the mmap write lock on the provided mm, not init_mm:

mm/ptdump.c:ptdump_walk_pgd() {
    mmap_write_lock(mm);
    while (range->start != range->end) {
        walk_page_range_debug(mm, range->start, range->end, ...);
        ...
    }
    mmap_write_unlock(mm);
}

Because kernel page tables are shared globally, this walk traverses the
exact same page table pages that vmap is operating on in init_mm.

If vmap only takes the mmap read lock on init_mm, and ptdump takes the mmap
write lock on current->mm or efi_mm, there is no mutual exclusion between
the two operations.

Could this allow ptdump to concurrently dereference the PTE pages that vmap
is freeing, resulting in a use-after-free?

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

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260723-series-vmap-race-fix-v6-0-8cc77dcc0018@kernel.org?part=1