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

["Lorenzo Stoakes (ARM)" <ljs@kernel.org>]

On 2026-07-15 12:14 -0700, Andrew Morton wrote:
> On Wed, 15 Jul 2026 15:16:08 +0100 "Lorenzo Stoakes (ARM)" <ljs@kernel.org> wrote:
>
> > On 2026-07-15 11:34 +0100, Kiryl Shutsemau wrote:
> > > On Tue, Jul 14, 2026 at 06:24:23PM +0100, Lorenzo Stoakes wrote:
> > > > Currently there is a nasty race between ptdump and vmap when attempting to
> > > > map a huge P4D, PMD or PUD entry:
> > >
> > > Nit: that's a strange order of levels :P
> >
> > Ha, seems I couldn't decide on ordering so went with something random :P
> >
> > Let's try 'P4D, PUD or PMD' instead :))
> >
> > >
> > > > Fix this by holding the mmap read lock in vmap_try_huge_*() when freeing
> > > > page tables.
> > >
> > > How about adding here something like:
> > >
> > >   The read lock is sufficient: ptdump is the only walker that must be
> > >   excluded and it holds the mmap write lock. Other holders of the read
> > >   lock may run concurrently, but each exclusively owns the range it
> > >   operates on and cannot reach the page tables freed here.
> >
> > You mean maybe I put the commit message on _too_ much of a diet? :)
> >
> > Yeah sure, sounds good.
>
> I made this changelog alteration:
>
> --- a/txt/mm-vmalloc-acquire-init_mm-lock-on-huge-vmap-to-avoid-ptdump-uaf.txt
> +++ b/txt/mm-vmalloc-acquire-init_mm-lock-on-huge-vmap-to-avoid-ptdump-uaf.txt
> @@ -103,6 +103,11 @@ walk_page_range_debug(), vmap takes no relevant locks at all.
>  Fix this by holding the mmap read lock in vmap_try_huge_*() when freeing
>  page tables.
>
> +The read lock is sufficient: ptdump is the only walker that must be
> +excluded and it holds the mmap write lock.  Other holders of the read lock
> +may run concurrently, but each exclusively owns the range it operates on
> +and cannot reach the page tables freed here.
> +
>  We also hold the lock while assigning the huge page table entry, which
>  means page table walkers observe only the huge or non-huge page table
>  entry.

Perfect, thanks!

>
> > >
> > > > +	/*
> > > > +	 * 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.
> > > > +	 */
> > >
> > > Same for the comment, maybe:
> > >
> > >       /*
> > >        * 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.
> > >        */
> >
> > Yeah that's better agreed.
> >
> > Let's replace it, but I think (being super nitty) with an extra blank line as
> > above.
>
> This?
>
> --- a/mm/vmalloc.c~mm-vmalloc-acquire-init_mm-lock-on-huge-vmap-to-avoid-ptdump-uaf-fix
> +++ a/mm/vmalloc.c
> @@ -163,12 +163,11 @@ static int vmap_try_huge_pmd(pmd_t *pmd,
>  		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).
> +	 * Acquire the mmap read lock to exclude ptdump, which walks kernel
> +	 * page tables it does not own under the mmap write lock.
>  	 *
> -	 * Therefore, acquire the mmap read lock to prevent use-after-free when
> -	 * freeing page tables.
> +	 * Concurrent read lock holders are safe: each exclusively owns the
> +	 * range it operates on and cannot reach this page table.
>  	 */

Yes that's great thanks!

>  #ifndef CONFIG_ARM64
>  	scoped_cond_guard(mmap_read_lock_try, return 0, &init_mm)
> _
>
>
>

Cheers, Lorenzo