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

[David CARLIER]

> TL;DR you're fixing what was an existing race because ptdump touches memory
  > it doesn't own, unsafely. 5ba2f0a15564 just made it more likely by
  > increasing the race window.

  Right, better framing. I'll rewrite the changelog around the pre-existing
  race and keep the Fixes tag only as the window-widener.

  > And on other arches we acquire the init_mm mmap_lock? I don't think we do
  > do we?

  My bad .., I had it backwards. Will drop the x86 wording.

  > Also you should have ptdump take the RCU lock and assert the RCU lock in
  > walk_page_range_debug() [...] rather than taking the RCU lock there.

  Will do. r
  > In fact, you need to list the callers [...] and explain, convincingly, why
  > they are all safe

  It s ownership. Every other walker works on a range it owns and is the only
  one mutating it:

    walk_kernel_page_table_range():
      openrisc DMA, loongarch/riscv set_memory, hugetlb_vmemmap remap
    walk_kernel_page_table_range_lockless():
      arm64 __change_memory_common, arm64 range_split_to_ptes

  Only ptdump walks the whole address space, including ranges vmalloc is
  promoting to huge PMDs, so only it can race a free. I ll spell it out.

  > - Check that none of the architectures that implement
  >   ptdump_state->effective_prot_pXX() and ptdump_state->note_page_pXX()
  >   callbacks sleep [...]

  Checked arm64/powerpc/s390/x86/riscv: callbacks only format into the
  preallocated seq_file buffer, no sleeping, and pagewalk.c has no
  cond_resched(). The only GFP_KERNEL bits (s390 markers) run before the walk.
  Will note it.

  I'll reply to the syzbot thread with the diagnosis too. v5 to follow.

  Cheers.