[PATCH v7] mm: pgtable: free kernel page tables via RCU to fix ptdump UAF

[David CARLIER]

Hi Andrew

On Sun, 5 Jul 2026 at 21:31, Andrew Morton <akpm at linux-foundation.org> wrote:
>
> On Thu,  2 Jul 2026 10:30:11 +0100 David Carlier <devnexen at gmail.com> wrote:
>
> > ptdump_walk_pgd() walks the kernel page tables under get_online_mems().
> > That does not stop vmalloc from freeing a kernel PTE page underneath the
> > walk.
> >
> > When vmap_try_huge_pmd() promotes a range to a huge PMD it collapses the
> > existing PTE table and frees it via pmd_free_pte_page(). On x86, riscv and
> > powerpc this runs without the init_mm mmap lock; only arm64 takes it, and
> > not on the block-split path. So ptdump can dereference a just-freed PTE
> > page, which is the use after free syzbot hit in ptdump_pte_entry().
> >
> > The race is not new. ptdump walks the whole kernel address space, including
> > ranges other code is actively mapping, so it reads page tables it does not
> > own. 5ba2f0a15564 ("mm: introduce deferred freeing for kernel page tables")
> > only widened the window; the Fixes tag points there for that reason.
> >
> > Every other walker works on a range it owns and is the only one mutating
> > it: set_memory() on arm64/riscv/loongarch, the arm64 block-split path, the
> > openrisc DMA path and the hugetlb_vmemmap remap. Nothing frees those ranges
> > concurrently, so they cannot race and do not need RCU. ptdump is the only
> > walker that traverses ranges it does not own.
> >
> > Defer the free by an RCU grace period. pagetable_free_kernel() now frees
> > via call_rcu() in both the async and non-async configs. The async path
> > still flushes the TLB first, then queues the per-page RCU free. The page
> > stays valid until any walk that may have observed it drops its RCU read
> > lock.
>
> Thanks.  A use-after-free is something we should attend to!
>
> AI review had some thoughts, but in a strange manner:
>         https://sashiko.dev/#/patchset/20260702093011.336036-1-devnexen@gmail.com
>

The review reads oddly (it couldn't quote the diff), but the four points
are valid:

- The init_mm walk still calls walk_kernel_page_table_range(), which
  asserts the mmap lock I dropped; it should use the lockless variant.
- ptdump_walk_pgd() also runs on efi_mm and current->mm, so the lock
  drop needs to be init_mm-only -- otherwise it walks user tables
  locklessly against munmap().
- The chunk end overflows at the top of the address space; pgd_addr_end()
  handles that.
- The RCU deferral misses powerpc: pmd_free_pte_page() frees the PTE
  synchronously and the ptdesc isn't flagged kernel, so it never reaches
  pagetable_free_kernel().

Cheers.