Re: [tip: x86/urgent] x86/mm/pat: Acquire init_mm write lock on collapse to avoid UAF

["Lorenzo Stoakes (ARM)" <ljs@kernel.org>]

On Tue, Sep 01, 2026 at 08:03:21AM +0200, Jiri Slaby wrote:
> On 01. 09. 26, 0:27, tip-bot2 for Lorenzo Stoakes (ARM) wrote:
> > The following commit has been merged into the x86/urgent branch of tip:
> >
> > Commit-ID:     be4f4ab413d15e2b44f6bcda3b607eb707a7712e
> > Gitweb:        https://git.kernel.org/tip/be4f4ab413d15e2b44f6bcda3b607eb707a7712e
> > Author:        Lorenzo Stoakes (ARM) <ljs@kernel.org>
> > AuthorDate:    Thu, 13 Aug 2026 12:01:24 +03:00
> > Committer:     Dave Hansen <dave.hansen@linux.intel.com>
> > CommitterDate: Mon, 31 Aug 2026 15:14:58 -07:00
>
> The committed patch to tip is bogus. It contains only the guard definition.

Dave - you've somehow applied this patch completely incorrectly to x86/urgent,
I'm not happy with this going to Linus in this form :/

Now the commit message and the actual patch are completely mismatched.

I'm not sure how tip resolves issues like these but is it possible to
replace this with the actual patch that was submitted please?

Thanks.

>
> > x86/mm/pat: Acquire init_mm write lock on collapse to avoid UAF
> >
> > x86 implements page attribute modification using its Change Page
> > Attributes (CPA) mechanism.
> >
> > This tracks properties of ranges such as cache mode through x86 page
> > attributes, and as part of that logic manipulates kernel page tables.
> >
> > Since commit 41d88484c71c ("x86/mm/pat: restore large ROX pages after
> > fragmentation") ranges of kernel page table entries can be collapsed into
> > huge page table entries as part of this logic.
> >
> > As part of this collapse, it frees the page tables which the collapsed
> > entries previously pointed to, and it does so without any relevant locks
> > being held to preclude concurrent kernel page table walkers.
> >
> > The only way this code can be reached is if CPA_COLLAPSE is specified, and
> > this is only set in set_memory_rox() via:
> >
> > set_memory_rox()
> > -> change_page_attr_set_clr()
> > -> cpa_flush()
> > -> cpa_collapse_large_pages()
> >
> > Notable users of this are execmem and bpf when manipulating executable
> > mappings.
> >
> > However, this is problematic for ptdump as it walks ranges it does not own
> > and thus runs the risk of a use-after-free on page tables freed underneath
> > it.
> >
> > In addition, concurrent CPA collapse operations are possible which can also
> > cause races.
> >
> > Resolve the issue by acquiring the mmap write lock on init_mm across the
> > whole operation.
> >
> > It is safe to acquire a sleeping lock as all the callers invoke
> > set_memory_rox() from process context and in any case,
> > change_page_attr_set_clr() calls vm_unmap_alias() which ultimately takes a
> > mutex, disallowing atomic context here.
> >
> > Fixes: 41d88484c71c ("x86/mm/pat: restore large ROX pages after fragmentation")
> > Signed-off-by: Lorenzo Stoakes (ARM) <ljs@kernel.org>
> > Signed-off-by: Mike Rapoport (Microsoft) <rppt@kernel.org>
> > Signed-off-by: Dave Hansen <dave.hansen@linux.intel.com>
> > Reviewed-by: Mike Rapoport (Microsoft) <rppt@kernel.org>
> > Reviewed-by: Kiryl Shutsemau (Meta) <kas@kernel.org>
> > Reviewed-by: David Hildenbrand (Arm) <david@kernel.org>
> > Reviewed-by: Dave Hansen <dave.hansen@linux.intel.com>
> > Reviewed-by: Will Deacon <will@kernel.org>
> > Reviewed-by: David Carlier <devnexen@gmail.com>
> > Tested-by: Atish Patra <atishp@meta.com>
> > Tested-by: Nikunj A Dadhania <nikunj@amd.com>

It renders all of these tags completly incorrect too.

> > Cc:stable@vger.kernel.org
> > Link: https://patch.msgid.link/20260813-cpa-fixes-v2-1-39b4ff90f91d@kernel.org
> > ---
> >   include/linux/mmap_lock.h | 2 ++
> >   1 file changed, 2 insertions(+)
> >
> > diff --git a/include/linux/mmap_lock.h b/include/linux/mmap_lock.h
> > index bec0eab..b8a13b8 100644
> > --- a/include/linux/mmap_lock.h
> > +++ b/include/linux/mmap_lock.h
> > @@ -630,6 +630,8 @@ static inline void mmap_read_unlock(struct mm_struct *mm)
> >   DEFINE_GUARD(mmap_read_lock, struct mm_struct *,
> >   	     mmap_read_lock(_T), mmap_read_unlock(_T))
> >   DEFINE_GUARD_COND(mmap_read_lock, _try, mmap_read_trylock(_T))
> > +DEFINE_GUARD(mmap_write_lock, struct mm_struct *,
> > +	     mmap_write_lock(_T), mmap_write_unlock(_T))

Yeah I meant obviously this isn't what the patch is.

> >   static inline void mmap_read_unlock_non_owner(struct mm_struct *mm)
> >   {
> >
>
> --
> js
> suse labs
>

--
Cheers, Lorenzo