Re: [PATCH] mm/ptdump: always stabilise against page table freeing using init_mm

[Lorenzo Stoakes]

On Sat, Jul 11, 2026 at 08:57:18AM +0100, Lorenzo Stoakes wrote:
> (+cc Dave as we were discussing on another thread)
>
> On Fri, Jul 10, 2026 at 01:29:54PM -0700, Andrew Morton wrote:
> > On Fri, 10 Jul 2026 14:29:21 +0100 Lorenzo Stoakes <ljs@xxxxxxxxxx> wrote:
> >
> > > x86 and arm64 invokes ptdump_walk_pgd() with non-init_mm mm whilst still
> > > walking kernel page table ranges.
> > >
> > > For x86 this is done in ptdump_curknl_show() and ptdump_efi_show(), the
> > > first passing current->mm, and the second passing efi_mm (we reach kernel
> > > mappings that init_mm protects for current->mm due to x86 cloning shared
> > > kernel page tables for arbitrary mm's).
> > >
> > > arm64 does so via ptdump_debugfs_register(), configured by efi_ptdump_info
> > > for efi ranges against efi_mm.
> > >
> > > The init_mm mmap lock is used to stabilise page table freeing against
> > > ptdump, so take a nested lock on init_mm to ensure that we are correctly
> > > stabilised.
> > >
> > > We take this after mmap write locking the non-init_mm mm. Nothing acquires
> > > the init_mm lock first before locking an arbitrary mm, so no deadlock is
> > > possible.
> > >
> > > Other fixes have been sent which update the two cases which can cause races
> > > with ptdump in init_mm ranges to acquire the init_mm mmap write lock - vmap
> > > and x86 CPA huge page promotion.
> > >
> > > For arm64, commit fa93b45fd397 ("arm64: Enable vmalloc-huge with ptdump")
> > > already provides exclusion against init_mm for the vmap case, which this
> > > patch also pairs with.
> > >
> > > The first point at which ptdump can race kernel page table freeing is
> > > commit b6bdb7517c3d ("mm/vmalloc: add interfaces to free unmapped page
> > > table"), so we target this in the Fixes tag.
> >
> > Does this have any known userspace impact?
>
> Taken in conjunction with the other fixes mentioned it resolves a UAF, so yes :)
>
> >
> > > Fixes: b6bdb7517c3d ("mm/vmalloc: add interfaces to free unmapped page table")
> >
> > Since 2018, so I won't make this a hotfix, OK?
> >
>
> No, this has to be a hotfix, it is part of solving a live UAF issue.
>
> Cheers, Lorenzo

Have put this patch in a series in [0], as easier to just keep everything
together and makes dependencies clear and what it's for.

Cheers, Lorenzo

[0]:https://lore.kernel.org/all/20260712-series-vmap-race-fix-v2-0-ad134cc3a12a@xxxxxxxxxx/