Re: [PATCH] x86/mm/pat: acquire mmap lock on page table free to avoid ptdump UAF

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:

Pre-existing issues:
- [High] The patch fails to protect ptdump invocations on mm_structs other than init_mm (such as current->mm or efi_mm), leaving them vulnerable to Use-After-Free.
- [High] The patch fails to protect lockless kernel page table walkers from a Use-After-Free race when freeing collapsed page tables.
--

--- Patch [1]: [PATCH] x86/mm/pat: acquire mmap lock on page table free to avoid ptdump UAF ---
commit 34992f845258302500edbd0c5e7fac8afe267207
Author: Lorenzo Stoakes <ljs@kernel.org>

x86/mm/pat: acquire mmap lock on page table free to avoid ptdump UAF

This commit attempts to fix a use-after-free issue when ptdump walks kernel
page tables concurrently with them being collapsed and freed by CPA. It adds
an mmap_read_lock on init_mm during the free operation.

> diff --git a/arch/x86/mm/pat/set_memory.c b/arch/x86/mm/pat/set_memory.c
> index d023a40a1e034..4c4b8244502fc 100644
> --- a/arch/x86/mm/pat/set_memory.c
> +++ b/arch/x86/mm/pat/set_memory.c

[ ... ]

> @@ -436,9 +437,16 @@ static void cpa_collapse_large_pages(struct cpa_data *cpa)
>  
>  	flush_tlb_all();
>  
> -	list_for_each_entry_safe(ptdesc, tmp, &pgtables, pt_list) {
> -		list_del(&ptdesc->pt_list);
> -		pagetable_free(ptdesc);
> +	/*
> +	 * ptdump might read these page tables, so avoid a use-after-free by
> +	 * acquiring the mmap read lock on init_mm (ptdump acquires the mmap
> +	 * write lock).
> +	 */
> +	scoped_guard(mmap_read_lock, &init_mm) {

[Severity: High]
This isn't a bug introduced by this patch, but does locking init_mm protect
ptdump invocations that use a different mm_struct?

For example, when reading /sys/kernel/debug/page_tables/current_kernel,
the kernel calls ptdump_curknl_show() which invokes ptdump on current->mm:

arch/x86/mm/debug_pagetables.c:ptdump_curknl_show() {
    ...
    ptdump_walk_pgd_level_debugfs(m, current->mm, false);
    ...
}

The ptdump walker will acquire the mmap_write_lock for current->mm, entirely
bypassing the init_mm lock added here. Can this still lead to a
use-after-free if set_memory_rox() concurrently frees a PTE page while
ptdump_curknl_show() is reading it?

> +		list_for_each_entry_safe(ptdesc, tmp, &pgtables, pt_list) {
> +			list_del(&ptdesc->pt_list);
> +			pagetable_free(ptdesc);

[Severity: High]
This is a pre-existing issue, but does mmap_read_lock protect against
lockless kernel page table walkers?

Functions like vmalloc_to_page() traverse kernel page tables locklessly:

mm/vmalloc.c:vmalloc_to_page() {
    ...
    ptep = pte_offset_kernel(pmd, addr);
    pte = ptep_get(ptep);
    ...
}

If a lockless walker reads a PMD and gets preempted, and concurrently
cpa_collapse_large_pages() collapses the PMD and synchronously frees the
page table to the buddy allocator via pagetable_free(), will the walker
dereference freed memory when it resumes?

Since mmap_read_lock does not block lockless walkers, would fixing this
properly require RCU-delayed freeing for kernel page tables instead of
synchronous freeing?

> +		}
> +	}
>  }

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260710-fix-cpa-ptdump-race-v1-1-d898699a7417@kernel.org?part=1