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

[Lorenzo Stoakes]

(+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