Re: [PATCH mm-hotfixes v6 3/5] x86/mm/pat: acquire init_mm read lock on attribute change to avoid UAF

[sashiko-bot@kernel.org]

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

Pre-existing issues:
- [High] Lockless callers of __change_page_attr_set_clr() remain vulnerable to Use-After-Free because set_memory_rox() and CPA_COLLAPSE operate on the direct map.
--

--- Patch [3]: [PATCH mm-hotfixes v6 3/5] x86/mm/pat: acquire init_mm read lock on attribute change to avoid UAF ---
commit 99a1d277a38cbe15d561ae13b70590f794c51988
Author: Lorenzo Stoakes (ARM) <ljs@kernel.org>
x86/mm/pat: acquire init_mm read lock on attribute change to avoid UAF

This commit resolves a use-after-free race between a lockless page table
walker and concurrent CPA collapse by acquiring the init_mm mmap read lock.
It also temporarily drops the lock during page table allocations to avoid
deadlocks with memory reclaim.

Link: https://lore.kernel.org/all/20260626163213.2284080-1-den@openvz.org/

> The CPA_COLLAPSE flag is only set by set_memory_rox(), which exclusively
> operates upon vmalloc ranges, and on x86 only within the module mapping
> space.
> 
> This is important, because some callers directly invoke
> __change_page_attr_set_clr(), bypassing this lock. However, none of these
> operate within the module mapping space.
> 
> * cpa_process_alias() - a recursive helper called by
>   __change_page_attr_set_clr().
> * __set_memory_enc_pgtable() - operates on the direct mapping and (via
>   __vmbus_establish_gpadl()) the vmalloc mapping space.
> * __set_pages_[n]p() - called by set_direct_map_[invalid, default,
>   valid]_noflush(), __kernel_map_pages() - operates on the direct map.

[Severity: High]
This is a pre-existing issue, but is the assumption that set_memory_rox()
exclusively operates upon vmalloc ranges accurate?

Looking at machine_kexec_prepare(), it appears to call set_memory_rox() on
control_page, which is a direct map address. If set_memory_rox() operates
on the direct map, could a concurrent vfree() trigger a use-after-free?

For example, if CPU 1 is doing kexec:

machine_kexec_prepare()
  set_memory_rox() -> sets CPA_COLLAPSE
    cpa_collapse_large_pages() -> replaces a page table with a huge page
                                  and frees the PTE page table via
                                  pagetable_free()

And CPU 2 is concurrently doing vfree():

vfree()
  vm_reset_perms()
    set_area_direct_map()
      set_direct_map_invalid_noflush()
        __set_pages_np() -> calls __change_page_attr_set_clr() locklessly

If CPU 2 performs a lockless walk on direct map pages that share the same
2MB region being collapsed by CPU 1, could it access the freed PTE page?

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260723-series-vmap-race-fix-v6-0-8cc77dcc0018@kernel.org?part=3