Re: [PATCH mm-hotfixes v5 2/5] x86/mm/pat: acquire init_mm write lock on collapse to avoid UAF

[sashiko-bot@kernel.org]

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

Pre-existing issues:
- [Critical] TOCTOU race in `_lookup_address_cpa` leading to kernel memory corruption.
- [High] Incomplete Use-After-Free fix against ptdump due to mmap_lock mismatch.
- [High] Use-after-free in `populate_pgd` rollback path due to premature page freeing.
--

--- Patch [2]: [PATCH mm-hotfixes v5 2/5] x86/mm/pat: acquire init_mm write lock on collapse to avoid UAF ---
commit b25bc68391fb2bdee5625f9af3d5344a0d10d51f
Author: Lorenzo Stoakes (ARM) <ljs@kernel.org>

x86/mm/pat: acquire init_mm write lock on collapse to avoid UAF
    
This commit adds scoped_guard(mmap_write_lock, &init_mm) to
cpa_collapse_large_pages() to avoid use-after-free issues with ptdump
and to serialize concurrent CPA walkers.

> diff --git a/arch/x86/mm/pat/set_memory.c b/arch/x86/mm/pat/set_memory.c
> index d023a40a1e034..d1e63f7d267ff 100644
> --- a/arch/x86/mm/pat/set_memory.c
> +++ b/arch/x86/mm/pat/set_memory.c
[ ... ]
> @@ -442,6 +443,18 @@ static void cpa_collapse_large_pages(struct cpa_data *cpa)
>  	}
>  }
>  
> +static void cpa_collapse_large_pages(struct cpa_data *cpa)
> +{
> +	/*
> +	 * Take the mmap write lock on init_mm to:
> +	 * - Avoid a use-after-free if raced by ptdump (which takes its own
> +	 *   write lock on init_mm).
> +	 * - Serialise concurrent CPA walkers.
> +	 */
> +	scoped_guard(mmap_write_lock, &init_mm)
> +		__cpa_collapse_large_pages(cpa);

[Severity: Critical]
This is a pre-existing issue, but does this lock actually serialize
concurrent CPA walkers like set_memory_rw() that might evaluate pmd_leaf()?

Other CPA walkers rely on cpa_lock and do not take init_mm's mmap lock.
If CPU1 executes __change_page_attr() via set_memory_rw(), it takes
cpa_lock, calls _lookup_address_cpa() -> lookup_address_in_pgd_attr(),
and evaluates pmd_leaf(*pmd) as false.

If CPU2 concurrently executes cpa_collapse_large_pages(), taking
mmap_write_lock(&init_mm) and pgd_lock, it collapses the PMD into a large
page (leaf).

CPU1 then continues and calls pte_offset_kernel(pmd), which reads the new
leaf PMD and incorrectly returns a pointer to the 2M data page itself.
Then set_pte_atomic() writes to this data page, corrupting physical memory.

Are concurrent standard CPA walkers able to race with this collapse since
they do not share the same lock?


[Severity: High]
This is a pre-existing issue, but does taking the mmap lock on init_mm
fully prevent races with ptdump?

When ptdump is triggered via debugfs, it calls
ptdump_walk_pgd_level_debugfs() on current->mm:

    ptdump_walk_pgd_level_debugfs(m, current->mm, false);

This takes mmap_write_lock(current->mm) in ptdump_walk_pgd(), which provides
no mutual exclusion against mmap_write_lock(&init_mm) taken here.

Since current->mm can be different from init_mm, won't ptdump concurrently
walk the shared kernel page tables while this function frees the PTE pages,
resulting in the same use-after-free this patch attempts to fix?

> +}
> +
>  static void cpa_flush(struct cpa_data *cpa, int cache)
>  {

[ ... ]

As a related note on pre-existing issues in this file:

[Severity: High]
This is a pre-existing issue, but is there a use-after-free in the
populate_pgd() rollback path due to premature page freeing?

In unmap_pte_range() during rollback (e.g., if populate_pgd() fails due to
OOM during dynamic encryption attribute changes via set_memory_encrypted()):

	if (try_to_free_pte_page((pte_t *)pmd_page_vaddr(*pmd))) {
		pmd_clear(pmd);

The PTE page is returned to the allocator by try_to_free_pte_page() before
pmd_clear() clears the PMD entry.

Could a concurrent ptdump or lockless walker read the PMD and access the
freed memory during this window?

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260717-series-vmap-race-fix-v5-0-606a0ac6d3e5@kernel.org?part=2