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

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

[Lorenzo Stoakes]

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.

Fixes: b6bdb7517c3d ("mm/vmalloc: add interfaces to free unmapped page table")
Cc: stable@vger.kernel.org
Signed-off-by: Lorenzo Stoakes <ljs@kernel.org>
---
 mm/ptdump.c | 7 +++++++
 1 file changed, 7 insertions(+)

diff --git a/mm/ptdump.c b/mm/ptdump.c
index 973020000096..6bef47b1a073 100644
--- a/mm/ptdump.c
+++ b/mm/ptdump.c
@@ -178,11 +178,18 @@ void ptdump_walk_pgd(struct ptdump_state *st, struct mm_struct *mm, pgd_t *pgd)
 
 	get_online_mems();
 	mmap_write_lock(mm);
+	/* To stabilise page tables we must hold the init_mm lock too. */
+	if (mm != &init_mm)
+		mmap_write_lock_nested(&init_mm, SINGLE_DEPTH_NESTING);
+
 	while (range->start != range->end) {
 		walk_page_range_debug(mm, range->start, range->end,
 				      &ptdump_ops, pgd, st);
 		range++;
 	}
+
+	if (mm != &init_mm)
+		mmap_write_unlock(&init_mm);
 	mmap_write_unlock(mm);
 	put_online_mems();
 

---
base-commit: a635d6748234582ea287c5ffeae28b9b23f91c7e
change-id: 20260710-b4-fix-non-init_mm-ptdump-016b88e2a2a6

Cheers,
-- 
Lorenzo Stoakes <ljs@kernel.org>

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

[Andrew Morton]

On Fri, 10 Jul 2026 14:29:21 +0100 Lorenzo Stoakes <ljs@kernel.org> 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?

> Fixes: b6bdb7517c3d ("mm/vmalloc: add interfaces to free unmapped page table")

Since 2018, so I won't make this a hotfix, OK?

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@kernel.org> 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

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

[Mike Rapoport]

On Fri, Jul 10, 2026 at 02:29:21PM +0100, Lorenzo Stoakes wrote:
> x86 and arm64 invokes ptdump_walk_pgd() with non-init_mm mm whilst still

Nit:            ^ invoke

> 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.
> 
> Fixes: b6bdb7517c3d ("mm/vmalloc: add interfaces to free unmapped page table")
> Cc: stable@vger.kernel.org
> Signed-off-by: Lorenzo Stoakes <ljs@kernel.org>
>
> ---
>  mm/ptdump.c | 7 +++++++
>  1 file changed, 7 insertions(+)
> 
> diff --git a/mm/ptdump.c b/mm/ptdump.c
> index 973020000096..6bef47b1a073 100644
> --- a/mm/ptdump.c
> +++ b/mm/ptdump.c
> @@ -178,11 +178,18 @@ void ptdump_walk_pgd(struct ptdump_state *st, struct mm_struct *mm, pgd_t *pgd)
>  
>  	get_online_mems();
>  	mmap_write_lock(mm);
> +	/* To stabilise page tables we must hold the init_mm lock too. */

Maybe

	/* To stabilise kernel page tables we must hold the init_mm lock too. */

Other than these nits

Reviewed-by: Mike Rapoport (Microsoft) <rppt@kernel.org>

-- 
Sincerely yours,
Mike.

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

[Lorenzo Stoakes]

On Sat, Jul 11, 2026 at 01:08:46PM +0300, Mike Rapoport wrote:
> On Fri, Jul 10, 2026 at 02:29:21PM +0100, Lorenzo Stoakes wrote:
> > x86 and arm64 invokes ptdump_walk_pgd() with non-init_mm mm whilst still
>
> Nit:            ^ invoke
>
> > 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.
> >
> > Fixes: b6bdb7517c3d ("mm/vmalloc: add interfaces to free unmapped page table")
> > Cc: stable@vger.kernel.org
> > Signed-off-by: Lorenzo Stoakes <ljs@kernel.org>
> >
> > ---
> >  mm/ptdump.c | 7 +++++++
> >  1 file changed, 7 insertions(+)
> >
> > diff --git a/mm/ptdump.c b/mm/ptdump.c
> > index 973020000096..6bef47b1a073 100644
> > --- a/mm/ptdump.c
> > +++ b/mm/ptdump.c
> > @@ -178,11 +178,18 @@ void ptdump_walk_pgd(struct ptdump_state *st, struct mm_struct *mm, pgd_t *pgd)
> >
> >  	get_online_mems();
> >  	mmap_write_lock(mm);
> > +	/* To stabilise page tables we must hold the init_mm lock too. */
>
> Maybe
>
> 	/* To stabilise kernel page tables we must hold the init_mm lock too. */
>
> Other than these nits

Ack on nits will fixup on respin.

>
> Reviewed-by: Mike Rapoport (Microsoft) <rppt@kernel.org>

Thanks!

>
> --
> Sincerely yours,
> Mike.

Cheers, Lorenzo

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@kernel.org> 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@kernel.org/