From: Dev Jain <dev.jain@arm.com>
To: David Carlier <devnexen@gmail.com>,
Andrew Morton <akpm@linux-foundation.org>
Cc: David Hildenbrand <david@kernel.org>,
Lorenzo Stoakes <ljs@kernel.org>,
"Liam R . Howlett" <liam@infradead.org>,
Vlastimil Babka <vbabka@kernel.org>,
Mike Rapoport <rppt@kernel.org>,
Suren Baghdasaryan <surenb@google.com>,
Michal Hocko <mhocko@suse.com>, Paul Walmsley <pjw@kernel.org>,
Palmer Dabbelt <palmer@dabbelt.com>,
Albert Ou <aou@eecs.berkeley.edu>,
Alexandre Ghiti <alex@ghiti.fr>,
Dave Hansen <dave.hansen@linux.intel.com>,
Lu Baolu <baolu.lu@linux.intel.com>,
syzbot+fd95a72470f5a44e464c@syzkaller.appspotmail.com,
linux-mm@kvack.org, linux-kernel@vger.kernel.org,
linux-riscv@lists.infradead.org
Subject: Re: [PATCH] mm: pgtable: free kernel page tables via RCU to fix ptdump UAF
Date: Thu, 2 Jul 2026 14:55:19 +0530 [thread overview]
Message-ID: <b71aeb67-fb48-42ed-a41d-d10274844a79@arm.com> (raw)
In-Reply-To: <20260702091841.332318-1-devnexen@gmail.com>
On 02/07/26 2:48 pm, David Carlier 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.
>
> On the read side walk_page_range_debug() walks the init_mm range in bounded
> chunks, taking rcu_read_lock() around each chunk and calling cond_resched()
> between them. A walker either sees the cleared PMD and skips, or keeps the
> page alive until it drops the lock; chunking keeps the read section short
> on a large kernel address space instead of holding RCU across the whole
> walk. The owned-range walkers are unchanged.
>
> Drop the mmap_write_lock() in ptdump_walk_pgd(). It never guarded against
> this free -- most architectures free the collapsed PTE table without it --
> and RCU now provides the synchronisation.
>
> ptdump callbacks run under RCU within a chunk, so they must not sleep. The
> arch note_page() and effective_prot() callbacks only format into the
> preallocated seq_file buffer; the only GFP_KERNEL marker setup runs before
> the walk, and cond_resched() happens between chunks, outside the read lock.
>
> Fixes: 5ba2f0a15564 ("mm: introduce deferred freeing for kernel page tables")
> Reported-by: syzbot+fd95a72470f5a44e464c@syzkaller.appspotmail.com
> Closes: https://lore.kernel.org/all/6a287988.39669fcc.33b062.00a0.GAE@google.com/T/
> Assisted-by: Claude:claude-opus-4-8
> Signed-off-by: David Carlier <devnexen@gmail.com>
> ---
Please update the patch version. I believe it should be v7 by now. And, please have
a changelog so people have some context.
WARNING: multiple messages have this Message-ID (diff)
From: Dev Jain <dev.jain@arm.com>
To: David Carlier <devnexen@gmail.com>,
Andrew Morton <akpm@linux-foundation.org>
Cc: David Hildenbrand <david@kernel.org>,
Lorenzo Stoakes <ljs@kernel.org>,
"Liam R . Howlett" <liam@infradead.org>,
Vlastimil Babka <vbabka@kernel.org>,
Mike Rapoport <rppt@kernel.org>,
Suren Baghdasaryan <surenb@google.com>,
Michal Hocko <mhocko@suse.com>, Paul Walmsley <pjw@kernel.org>,
Palmer Dabbelt <palmer@dabbelt.com>,
Albert Ou <aou@eecs.berkeley.edu>,
Alexandre Ghiti <alex@ghiti.fr>,
Dave Hansen <dave.hansen@linux.intel.com>,
Lu Baolu <baolu.lu@linux.intel.com>,
syzbot+fd95a72470f5a44e464c@syzkaller.appspotmail.com,
linux-mm@kvack.org, linux-kernel@vger.kernel.org,
linux-riscv@lists.infradead.org
Subject: Re: [PATCH] mm: pgtable: free kernel page tables via RCU to fix ptdump UAF
Date: Thu, 2 Jul 2026 14:55:19 +0530 [thread overview]
Message-ID: <b71aeb67-fb48-42ed-a41d-d10274844a79@arm.com> (raw)
In-Reply-To: <20260702091841.332318-1-devnexen@gmail.com>
On 02/07/26 2:48 pm, David Carlier 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.
>
> On the read side walk_page_range_debug() walks the init_mm range in bounded
> chunks, taking rcu_read_lock() around each chunk and calling cond_resched()
> between them. A walker either sees the cleared PMD and skips, or keeps the
> page alive until it drops the lock; chunking keeps the read section short
> on a large kernel address space instead of holding RCU across the whole
> walk. The owned-range walkers are unchanged.
>
> Drop the mmap_write_lock() in ptdump_walk_pgd(). It never guarded against
> this free -- most architectures free the collapsed PTE table without it --
> and RCU now provides the synchronisation.
>
> ptdump callbacks run under RCU within a chunk, so they must not sleep. The
> arch note_page() and effective_prot() callbacks only format into the
> preallocated seq_file buffer; the only GFP_KERNEL marker setup runs before
> the walk, and cond_resched() happens between chunks, outside the read lock.
>
> Fixes: 5ba2f0a15564 ("mm: introduce deferred freeing for kernel page tables")
> Reported-by: syzbot+fd95a72470f5a44e464c@syzkaller.appspotmail.com
> Closes: https://lore.kernel.org/all/6a287988.39669fcc.33b062.00a0.GAE@google.com/T/
> Assisted-by: Claude:claude-opus-4-8
> Signed-off-by: David Carlier <devnexen@gmail.com>
> ---
Please update the patch version. I believe it should be v7 by now. And, please have
a changelog so people have some context.
_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv
next prev parent reply other threads:[~2026-07-02 9:25 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-07-02 9:18 [PATCH] mm: pgtable: free kernel page tables via RCU to fix ptdump UAF David Carlier
2026-07-02 9:18 ` David Carlier
2026-07-02 9:25 ` Dev Jain [this message]
2026-07-02 9:25 ` Dev Jain
-- strict thread matches above, loose matches on Subject: below --
2026-06-30 4:10 David Carlier
2026-06-30 4:10 ` David Carlier
2026-07-01 5:42 ` Dev Jain
2026-07-01 5:42 ` Dev Jain
2026-07-01 5:57 ` David CARLIER
2026-07-01 5:57 ` David CARLIER
2026-07-01 12:26 ` Dev Jain
2026-07-01 12:26 ` Dev Jain
2026-07-01 15:58 ` David Hildenbrand (Arm)
2026-07-01 15:58 ` David Hildenbrand (Arm)
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=b71aeb67-fb48-42ed-a41d-d10274844a79@arm.com \
--to=dev.jain@arm.com \
--cc=akpm@linux-foundation.org \
--cc=alex@ghiti.fr \
--cc=aou@eecs.berkeley.edu \
--cc=baolu.lu@linux.intel.com \
--cc=dave.hansen@linux.intel.com \
--cc=david@kernel.org \
--cc=devnexen@gmail.com \
--cc=liam@infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=linux-riscv@lists.infradead.org \
--cc=ljs@kernel.org \
--cc=mhocko@suse.com \
--cc=palmer@dabbelt.com \
--cc=pjw@kernel.org \
--cc=rppt@kernel.org \
--cc=surenb@google.com \
--cc=syzbot+fd95a72470f5a44e464c@syzkaller.appspotmail.com \
--cc=vbabka@kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.