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

[Lorenzo Stoakes]

On 2026-07-13 17:42 +0100, Kiryl Shutsemau wrote:
> On Sun, Jul 12, 2026 at 11:42:24AM +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.
>
> <... skip 145 lines of commit message :P >
>
> The code looks good to me, but I think the commit message needs some
> love. It is long, and the pieces of the story are scattered: the race
> itself only shows up around the middle, after several paragraphs of
> ptdump background (including the arm32 and EFI notes that the text
> itself says are not relevant to the bug), and the one genuinely subtle
> part -- why the read lock is sufficient -- is not spelled out at all.
>
> Something along these lines would be much easier to follow:
>
> 1. The race, up front. Diagram, if we you feel like it;
> 2. The fix, and why the read lock is enough;
> 3. Why a trylock;
> 4. The arm64 wrinkle and the temporary ifdeffery patch 4 removes;
> 5. Secondary changes (guard class, walk_page_range_debug() assert);
> 6. History, if you feel like it.
>
> Point 2 is the one I care about most -- the same reasoning would also
> help in the comment in vmap_try_huge_pmd(), where "Therefore, acquire
> the mmap read lock" is doing a lot of unexplained work.
>
> --
>   Kiryl Shutsemau / Kirill A. Shutemov
>


Yeah that's fair, I will reword!

Cheers, Lorenzo