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

[Andrew Morton <akpm@linux-foundation.org>]

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.

> >
> > > +	/*
> > > +	 * 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.
 	 */
 #ifndef CONFIG_ARM64
 	scoped_cond_guard(mmap_read_lock_try, return 0, &init_mm)
_