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

[Kiryl Shutsemau]

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

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

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

With that:

Reviewed-by: Kiryl Shutsemau <kas@xxxxxxxxxx>

-- 
  Kiryl Shutsemau / Kirill A. Shutemov