Linux-ARM-Kernel Archive on lore.kernel.org
 help / color / mirror / Atom feed
From: "Borah, Chaitanya Kumar" <chaitanya.kumar.borah@intel.com>
To: "Lorenzo Stoakes (ARM)" <ljs@kernel.org>,
	Andrew Morton <akpm@linux-foundation.org>,
	Suren Baghdasaryan <surenb@google.com>,
	"Liam R. Howlett" <liam@infradead.org>,
	Vlastimil Babka <vbabka@kernel.org>,
	"Shakeel Butt" <shakeel.butt@linux.dev>,
	David Hildenbrand <david@kernel.org>,
	"Mike Rapoport" <rppt@kernel.org>, Michal Hocko <mhocko@suse.com>,
	Uladzislau Rezki <urezki@gmail.com>,
	Toshi Kani <toshi.kani@hpe.com>,
	Dave Hansen <dave.hansen@linux.intel.com>,
	Andy Lutomirski <luto@kernel.org>,
	"Peter Zijlstra" <peterz@infradead.org>,
	Thomas Gleixner <tglx@kernel.org>,
	"Ingo Molnar" <mingo@redhat.com>, Borislav Petkov <bp@alien8.de>,
	<x86@kernel.org>, "H. Peter Anvin" <hpa@zytor.com>,
	Kiryl Shutsemau <kas@kernel.org>,
	"Catalin Marinas" <catalin.marinas@arm.com>,
	Will Deacon <will@kernel.org>, Dev Jain <dev.jain@arm.com>,
	Ryan Roberts <ryan.roberts@arm.com>
Cc: David Carlier <devnexen@gmail.com>, <linux-mm@kvack.org>,
	<linux-kernel@vger.kernel.org>, <bpf@vger.kernel.org>,
	<linux-arm-kernel@lists.infradead.org>,
	"Denis V. Lunev" <den@virtuozzo.com>, <stable@vger.kernel.org>,
	"intel-gfx@lists.freedesktop.org"
	<intel-gfx@lists.freedesktop.org>,
	"intel-xe@lists.freedesktop.org" <intel-xe@lists.freedesktop.org>
Subject: [REGRESSION]: [PATCH mm-hotfixes v5 3/5] x86/mm/pat: acquire init_mm read lock on attribute change to avoid UAF
Date: Thu, 23 Jul 2026 12:00:42 +0530	[thread overview]
Message-ID: <80993b70-352f-4069-84c7-39a04c061e98@intel.com> (raw)
In-Reply-To: <20260717-series-vmap-race-fix-v5-3-606a0ac6d3e5@kernel.org>

Hello Lorenzo,

On 7/17/2026 11:00 PM, Lorenzo Stoakes (ARM) wrote:
> A previous commit protected us against races between ptdump and CPA
> collapse, however one still exists between attribute changes and collapse
> as reported by Denis V. Lunev (linked).
> 
> When an attribute change arises, a lockless page table walker obtains a PTE
> entry, which is later written to via set_pte_atomic():
> 
> ...
> -> change_page_attr_set_clr()
> -> __change_page_attr_set_clr()
> -> __change_page_attr()
> 	-> _lookup_address_cpa()
> 	-> lookup_address_in_pgd_attr()
> 	-> [ lockless page table walker ]
> -> set_pte_atomic()
> 
> There is nothing preventing a concurrent CPA collapse which can free the
> PTE that was retrieved here, resulting in a use-after-free.
> 
> With the mmap write lock taken on init_mm over CPA collapse, we can now
> resolve this race by acquiring an mmap read lock on init_mm over
> __change_page_attr_set_clr().
> 
> This locks across the whole operation over which the walk and the PTE entry
> write occurs, solving the race.
> 
> It is safe to do this here, as no spinlocks are held upon entry to
> __change_page_attr_set_clr().
> 
> 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.
> * kernel_[un]map_pages_in_pgd() - operates on EFI ranges.
> 
> This work is based upon Denis V. Lunev's excellent analysis of the bug with
> gratitude.
> 

This seems to be causing regression in our linux-next CI [1] on some of 
the older machines (fi-elk-e7500, fi-ilk-650, fi-pnv-d510)

<4> [196.236867] ======================================================
<4> [196.236878] WARNING: possible circular locking dependency detected
<4> [196.236890] 7.2.0-rc4-next-20260720-next-20260720-g3fe08b9796f3+ #1 
Tainted: G S   U       L
<4> [196.236906] ------------------------------------------------------
<4> [196.236916] core_hotunplug/5687 is trying to acquire lock:
<4> [196.236927] ffffffff839048b8 ((init_mm).mmap_lock){++++}-{4:4}, at: 
change_page_attr_set_clr+0x10a/0x220
<4> [196.236958]
but task is already holding lock:
<4> [196.236969] ffff88810c852238 (&vm->mutex){+.+.}-{4:4}, at: 
i915_ggtt_driver_release+0xab/0x260 [i915]
<4> [196.237572]
which lock already depends on the new lock.
<4> [196.237585]
the existing dependency chain (in reverse order) is:
<4> [196.237597]
-> #2 (&vm->mutex){+.+.}-{4:4}:
<4> [196.237617]        i915_gem_shrinker_taints_mutex+0x35/0x70 [i915]
<4> [196.238267]        i915_address_space_init+0x226/0x2a0 [i915]
<4> [196.238961]        i915_ggtt_init_hw+0x2c/0x140 [i915]
<4> [196.239638]        i915_driver_hw_probe+0x208/0x380 [i915]
<4> [196.240260]        i915_driver_probe+0x113/0x5b0 [i915]
<4> [196.240883]        i915_pci_probe+0xe0/0x1d0 [i915]

Detailed log can be seen found in [2]

We confirmed that reverting the patch solves the issue.

Could you please check why the patch causes this regression and provide
a fix if necessary?

Regards
Chaitanya

[1] https://intel-gfx-ci.01.org/tree/linux-next/combined-alt.html?
[2] 
https://intel-gfx-ci.01.org/tree/linux-next/next-20260720/fi-ilk-650/igt@core_hotunplug@unbind-rebind.html

-- Bisect Logs --

git bisect start
# status: waiting for both good and bad commits
# good: [2b74f1f2024486c7a81915528b6aa7f8f5daa021] Merge patch series 
"software node: provide support for fw_devlink"
git bisect good 2b74f1f2024486c7a81915528b6aa7f8f5daa021
# status: waiting for bad commit, 1 good commit known
# bad: [3fe08b9796f36ef437ab9328e7dd1e5ff2d66603] Add linux-next 
specific files for 20260720
git bisect bad 3fe08b9796f36ef437ab9328e7dd1e5ff2d66603
# bad: [19137e3cffc35f327bd14d7b8b02f739f1e5c7bc] Merge branch 'main' of 
ssh://git@gitolite.kernel.org/pub/scm/linux/kernel/git/netdev/net-next.git
git bisect bad 19137e3cffc35f327bd14d7b8b02f739f1e5c7bc
# skip: [4f9e9b2e992ca79e090771e244bc2096709e13c6] Merge branch 
'mm-unstable' of 
ssh://git@gitolite.kernel.org/pub/scm/linux/kernel/git/akpm/mm
git bisect skip 4f9e9b2e992ca79e090771e244bc2096709e13c6
# good: [1aa4e2ed7caafbbbedff89fb226a982413469baf] dt-bindings: clock: 
Replace bouncing emails
git bisect good 1aa4e2ed7caafbbbedff89fb226a982413469baf
# good: [daec24a5ed5da77a108e246ad77aa8b889911f93] wifi: iwlwifi: 
validate payload length in iwl_pnvm_complete_fn
git bisect good daec24a5ed5da77a108e246ad77aa8b889911f93
# bad: [247e42b76590a27408e5eea7009067cac5ad9feb] Merge branch 
'for-next' of 
ssh://git@gitolite.kernel.org/pub/scm/linux/kernel/git/peter.chen/cix.git
git bisect bad 247e42b76590a27408e5eea7009067cac5ad9feb
# bad: [d623282ba80e07d3bd7608d905b143041f865f3b] Merge branch 
'tty-linus' of 
ssh://git@gitolite.kernel.org/pub/scm/linux/kernel/git/gregkh/tty.git
git bisect bad d623282ba80e07d3bd7608d905b143041f865f3b
# good: [6f5156d7a31a8c3b0f34af4675c9299c8f877cbe] Merge tag 
'pm-7.2-rc4' of 
git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm
git bisect good 6f5156d7a31a8c3b0f34af4675c9299c8f877cbe
# good: [7d6ca51a444234ca436d7c19282825797507fe82] Merge tag 
'drm-fixes-2026-07-18-1' of https://gitlab.freedesktop.org/drm/kernel
git bisect good 7d6ca51a444234ca436d7c19282825797507fe82
# bad: [499079fbac564b04cce6a750111bf1c36aaeb4d5] Merge branch 
'mm-hotfixes-unstable' of 
ssh://git@gitolite.kernel.org/pub/scm/linux/kernel/git/akpm/mm
git bisect bad 499079fbac564b04cce6a750111bf1c36aaeb4d5
# good: [a2b81de43ca64832fe09844bbf97d1251115d80f] Merge tag 
'io_uring-7.2-20260717' of 
git://git.kernel.org/pub/scm/linux/kernel/git/axboe/linux
git bisect good a2b81de43ca64832fe09844bbf97d1251115d80f
# bad: [b55b09b68a9cd81d2c1f4004e4c258cbfa61b16f] x86/mm/pat: acquire 
init_mm read lock on attribute change to avoid UAF
git bisect bad b55b09b68a9cd81d2c1f4004e4c258cbfa61b16f
# good: [841587a3eaad22b288d9701f783e20a5046e76b4] mm/hugetlb: fix null 
nodemask in alloc_fresh_hugetlb_folio
git bisect good 841587a3eaad22b288d9701f783e20a5046e76b4
# good: [2272f397e66bd9f78c2e1f524f8e7b1e01e15005] ocfs2: fix boundary 
check in ocfs2_check_dir_entry() to use buffer offset
git bisect good 2272f397e66bd9f78c2e1f524f8e7b1e01e15005
# good: [a5bba3c7f83071427f5f770b53ce5c59f8ed0af0] fs/proc/task_mmu: fix 
PAGEMAP_SCAN written state for PMD holes
git bisect good a5bba3c7f83071427f5f770b53ce5c59f8ed0af0
# good: [f539349310317df97b5f1b501c4c6dc2a73c3c37] mm/vmalloc: acquire 
init_mm lock on huge vmap to avoid ptdump UAF
git bisect good f539349310317df97b5f1b501c4c6dc2a73c3c37
# good: [c6d14c413d47a772a54f6aa7e545a15abc06b1d0] x86/mm/pat: acquire 
init_mm write lock on collapse to avoid UAF
git bisect good c6d14c413d47a772a54f6aa7e545a15abc06b1d0
# first bad commit: [b55b09b68a9cd81d2c1f4004e4c258cbfa61b16f] 
x86/mm/pat: acquire init_mm read lock on attribute change to avoid UAF


> Link: https://lore.kernel.org/all/20260626163213.2284080-1-den@openvz.org/
> Fixes: 41d88484c71c ("x86/mm/pat: restore large ROX pages after fragmentation")
> Cc: stable@vger.kernel.org
> Signed-off-by: Lorenzo Stoakes (ARM) <ljs@kernel.org>
> ---
>   arch/x86/mm/pat/set_memory.c | 4 +++-
>   1 file changed, 3 insertions(+), 1 deletion(-)
> 
> diff --git a/arch/x86/mm/pat/set_memory.c b/arch/x86/mm/pat/set_memory.c
> index d1e63f7d267f..301fb9e77d91 100644
> --- a/arch/x86/mm/pat/set_memory.c
> +++ b/arch/x86/mm/pat/set_memory.c
> @@ -2122,7 +2122,9 @@ static int change_page_attr_set_clr(unsigned long *addr, int numpages,
>   	cpa.curpage = 0;
>   	cpa.force_split = force_split;
>   
> -	ret = __change_page_attr_set_clr(&cpa, 1);
> +	/* Avoid race with concurrent CPA collapse. */
> +	scoped_guard(mmap_read_lock, &init_mm)
> +		ret = __change_page_attr_set_clr(&cpa, 1);
>   
>   	/*
>   	 * Check whether we really changed something:
> 



  parent reply	other threads:[~2026-07-23  6:33 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-07-17 17:30 [PATCH mm-hotfixes v5 0/5] mm: fix UAF caused by race between ptdump and vmap pgtable freeing Lorenzo Stoakes (ARM)
2026-07-17 17:30 ` [PATCH mm-hotfixes v5 1/5] mm/vmalloc: acquire init_mm lock on huge vmap to avoid ptdump UAF Lorenzo Stoakes (ARM)
2026-07-17 17:30 ` [PATCH mm-hotfixes v5 2/5] x86/mm/pat: acquire init_mm write lock on collapse to avoid UAF Lorenzo Stoakes (ARM)
2026-07-17 17:30 ` [PATCH mm-hotfixes v5 3/5] x86/mm/pat: acquire init_mm read lock on attribute change " Lorenzo Stoakes (ARM)
2026-07-18 10:54   ` Mike Rapoport
2026-07-18 14:28     ` Lorenzo Stoakes (ARM)
2026-07-23  6:30   ` Borah, Chaitanya Kumar [this message]
2026-07-23 14:18     ` [REGRESSION]: " Lorenzo Stoakes (ARM)
2026-07-27  9:00       ` Borah, Chaitanya Kumar
2026-07-27 11:25         ` Lorenzo Stoakes (ARM)
2026-07-17 17:30 ` [PATCH mm-hotfixes v5 4/5] mm/ptdump: always stabilise against page table freeing using init_mm Lorenzo Stoakes (ARM)
2026-07-17 17:30 ` [PATCH mm-hotfixes v5 5/5] arm64: remove redundant concurrent ptdump UAF mitigation Lorenzo Stoakes (ARM)
2026-07-17 19:29 ` [PATCH mm-hotfixes v5 0/5] mm: fix UAF caused by race between ptdump and vmap pgtable freeing Andrew Morton

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=80993b70-352f-4069-84c7-39a04c061e98@intel.com \
    --to=chaitanya.kumar.borah@intel.com \
    --cc=akpm@linux-foundation.org \
    --cc=bp@alien8.de \
    --cc=bpf@vger.kernel.org \
    --cc=catalin.marinas@arm.com \
    --cc=dave.hansen@linux.intel.com \
    --cc=david@kernel.org \
    --cc=den@virtuozzo.com \
    --cc=dev.jain@arm.com \
    --cc=devnexen@gmail.com \
    --cc=hpa@zytor.com \
    --cc=intel-gfx@lists.freedesktop.org \
    --cc=intel-xe@lists.freedesktop.org \
    --cc=kas@kernel.org \
    --cc=liam@infradead.org \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=ljs@kernel.org \
    --cc=luto@kernel.org \
    --cc=mhocko@suse.com \
    --cc=mingo@redhat.com \
    --cc=peterz@infradead.org \
    --cc=rppt@kernel.org \
    --cc=ryan.roberts@arm.com \
    --cc=shakeel.butt@linux.dev \
    --cc=stable@vger.kernel.org \
    --cc=surenb@google.com \
    --cc=tglx@kernel.org \
    --cc=toshi.kani@hpe.com \
    --cc=urezki@gmail.com \
    --cc=vbabka@kernel.org \
    --cc=will@kernel.org \
    --cc=x86@kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox