include/linux/mmap_lock.h | 2 ++ 1 file changed, 2 insertions(+)
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
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>
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))
static inline void mmap_read_unlock_non_owner(struct mm_struct *mm)
{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.
> 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>
> 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))
>
> static inline void mmap_read_unlock_non_owner(struct mm_struct *mm)
> {
>
--
js
suse labs
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
On 9/1/26 00:10, Lorenzo Stoakes (ARM) wrote: > Dave - you've somehow applied this patch completely incorrectly to x86/urgent, > I'm not happy with this going to Linus in this form :/ Me neither, btw. So, here it is applied: > https://git.kernel.org/pub/scm/linux/kernel/git/daveh/devel.git/log/?h=cpa1 The diffstat exactly matches the mbox that I sucked in. I'm going to launch some tests overnight. The only things I really munged were a little merge issue with patch 1, a SoB ordering issue in patch 3, and a few scattered rewordings in the commit messages. Not pushed to x86/urgent, yet.
On Tue, Sep 01, 2026 at 04:36:38PM -0700, Dave Hansen wrote: > On 9/1/26 00:10, Lorenzo Stoakes (ARM) wrote: > > Dave - you've somehow applied this patch completely incorrectly to x86/urgent, > > I'm not happy with this going to Linus in this form :/ > > Me neither, btw. > > So, here it is applied: > > > https://git.kernel.org/pub/scm/linux/kernel/git/daveh/devel.git/log/?h=cpa1 > > The diffstat exactly matches the mbox that I sucked in. I'm going to > launch some tests overnight. > > The only things I really munged were a little merge issue with patch 1, > a SoB ordering issue in patch 3, and a few scattered rewordings in the > commit messages. > > Not pushed to x86/urgent, yet. I have to say I'm confused with today's batch of tip-bot emails saying Ingo applied these to x86/mm :/ -- Sincerely yours, Mike.
On 9/8/26 02:32, Mike Rapoport wrote: > I have to say I'm confused with today's batch of tip-bot emails saying Ingo > applied these to x86/mm :/ Just a reminder that we have x86/urgent which will be going to Linus like today. There's also x86/mm which goes up in the next merge window.. The "Fix effective RW computation" patch is getting broken out and is going to wait for the next merge window. We don't want it sitting in mainline generating warnings, especially false positives like the one this weekend. That's not to disparage the patch; it's overall the right thing to do. Sound good?
On 9/8/26 06:58, Dave Hansen wrote: > On 9/8/26 02:32, Mike Rapoport wrote: >> I have to say I'm confused with today's batch of tip-bot emails saying Ingo >> applied these to x86/mm :/ > Just a reminder that we have x86/urgent which will be going to Linus > like today. There's also x86/mm which goes up in the next merge window.. > > The "Fix effective RW computation" patch is getting broken out and is > going to wait for the next merge window. We don't want it sitting in > mainline generating warnings, especially false positives like the one > this weekend. That's not to disparage the patch; it's overall the right > thing to do. > > Sound good? ... and no, that isn't the current state of x86/mm and x86/urgent. But that's where I _want_ to end up.
On 9/8/26 15:58, Dave Hansen wrote: > On 9/8/26 02:32, Mike Rapoport wrote: >> I have to say I'm confused with today's batch of tip-bot emails saying Ingo >> applied these to x86/mm :/ > > Just a reminder that we have x86/urgent which will be going to Linus > like today. There's also x86/mm which goes up in the next merge window.. However x86/urgent (at least as visible [1]) doesn't contain anything from this series, and x86/mm has everything except "Fix effective RW computation". But tip/urgent does merge x86/mm so hopefully it means it's really going to Linus now-ish (and not next merge window)? It just doesn't have "urgent" in the branch name? > The "Fix effective RW computation" patch is getting broken out and is > going to wait for the next merge window. We don't want it sitting in > mainline generating warnings, especially false positives like the one > this weekend. That's not to disparage the patch; it's overall the right > thing to do. So that means adding it to x86/mm after the current one is sent as urgent? Just wanted to double check, thanks. Vlastimil [1] https://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git/ > Sound good?
On Tue, Sep 08, 2026 at 12:32:17PM +0300, Mike Rapoport wrote: > On Tue, Sep 01, 2026 at 04:36:38PM -0700, Dave Hansen wrote: > > On 9/1/26 00:10, Lorenzo Stoakes (ARM) wrote: > > > Dave - you've somehow applied this patch completely incorrectly to x86/urgent, > > > I'm not happy with this going to Linus in this form :/ > > > > Me neither, btw. > > > > So, here it is applied: > > > > > https://git.kernel.org/pub/scm/linux/kernel/git/daveh/devel.git/log/?h=cpa1 > > > > The diffstat exactly matches the mbox that I sucked in. I'm going to > > launch some tests overnight. > > > > The only things I really munged were a little merge issue with patch 1, > > a SoB ordering issue in patch 3, and a few scattered rewordings in the > > commit messages. > > > > Not pushed to x86/urgent, yet. > > I have to say I'm confused with today's batch of tip-bot emails saying Ingo > applied these to x86/mm :/ Since I don't seem to get replies to mails on this topic, I can only _guess_ :), but: * I see patches in x86/urgent that aren't in x86/mm, so that rules out x86/mm being a stepping stone in the process. * x86/urgent has had more patches added to it, for series sent after this one, which fix bugs from 2024, 2025 etc. So that's all working as expected. * We've already highlighted that this series fixes bugs users are seeing in production, so I don't see why it'd be deprioritised. * It's coming form a private dev repo/branch so I can't imagine it's a wayward script (but maybe?) * The patches have been in linux-next for a while (maybe Dave/Ingo wanted them there longer? They were there for weeks before the ->x86 stuff though). Perhaps the reported bug that you've now fixed was the hold up? I guess who knows :) So yeah, I'm also rather confused :) Ah well. I guess taking them through the mm tree wouldn't really be sensible/the right thing to do at this stage, so I guess let's hope they land for 7.4. > > -- > Sincerely yours, > Mike. -- Cheers, Lorenzo
On Tue, Sep 01, 2026 at 04:36:38PM -0700, Dave Hansen wrote: > On 9/1/26 00:10, Lorenzo Stoakes (ARM) wrote: > > Dave - you've somehow applied this patch completely incorrectly to x86/urgent, > > I'm not happy with this going to Linus in this form :/ > > Me neither, btw. Yeah, sorry to complain so loudly, but just obviously want to make sure these are sorted correctly! > > So, here it is applied: > > > https://git.kernel.org/pub/scm/linux/kernel/git/daveh/devel.git/log/?h=cpa1 > > The diffstat exactly matches the mbox that I sucked in. I'm going to > launch some tests overnight. Thanks! I had a look through and all LGTM :) > > The only things I really munged were a little merge issue with patch 1, > a SoB ordering issue in patch 3, and a few scattered rewordings in the > commit messages. That's all good of course! > > Not pushed to x86/urgent, yet. Ack, understood that you want to beat them about a bit with some tests, let me know if there's anything else you need on these! -- Cheers, Lorenzo
© 2016 - 2026 Red Hat, Inc.