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 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.

>
> > +	/*
> > +	 * 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.

>
> With that:
>
> Reviewed-by: Kiryl Shutsemau <kas@kernel.org>

Thanks!

>
> --
>   Kiryl Shutsemau / Kirill A. Shutemov
>

Andrew - could you fix the commit message and the comment as above? Can respin
if needed.

Thanks, Lorenzo