From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id 2D920C44508 for ; Wed, 15 Jul 2026 15:25:14 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id AE26B6B009E; Wed, 15 Jul 2026 11:25:12 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id A92F96B00A3; Wed, 15 Jul 2026 11:25:12 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 95D6B6B00A5; Wed, 15 Jul 2026 11:25:12 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0016.hostedemail.com [216.40.44.16]) by kanga.kvack.org (Postfix) with ESMTP id 4BC9B6B009E for ; Wed, 15 Jul 2026 11:25:12 -0400 (EDT) Received: from smtpin19.hostedemail.com (lb01a-stub [10.200.18.249]) by unirelay08.hostedemail.com (Postfix) with ESMTP id 94832140216 for ; Wed, 15 Jul 2026 15:25:11 +0000 (UTC) X-FDA: 84991384422.19.74461C3 Received: from sea.source.kernel.org (sea.source.kernel.org [172.234.252.31]) by imf28.hostedemail.com (Postfix) with ESMTP id EEC0EC0009 for ; Wed, 15 Jul 2026 15:25:09 +0000 (UTC) Authentication-Results: imf28.hostedemail.com; dkim=pass header.d=kernel.org header.s=k20260515 header.b=VwMy915a; spf=pass (imf28.hostedemail.com: domain of will@kernel.org designates 172.234.252.31 as permitted sender) smtp.mailfrom=will@kernel.org; dmarc=pass (policy=quarantine) header.from=kernel.org ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1784129110; h=from:from:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type:content-transfer-encoding: in-reply-to:in-reply-to:references:references:dkim-signature; bh=qCp0Z/LIk1edhZq1e91Hff3OKVN7JtELVDWP1PDw0J0=; b=Qz7PZXfYShEXc/RsIVzOHrGLnlrXw47T1xLLHfTIGtoLStMO2d82IrF8XiJj0wa2oTQdL7 WN67bMIBPfX4AvqwtL+WDO5p+fO71O1dnf+Hfkt3fOupIIsRRz1yhTxEi4oSanlCzzYB0W SMhb6CTkJ9rvOkX1A4DU7Sv6vobOJek= ARC-Authentication-Results: i=1; imf28.hostedemail.com; dkim=pass header.d=kernel.org header.s=k20260515 header.b=VwMy915a; spf=pass (imf28.hostedemail.com: domain of will@kernel.org designates 172.234.252.31 as permitted sender) smtp.mailfrom=will@kernel.org; dmarc=pass (policy=quarantine) header.from=kernel.org ARC-Seal: i=1; a=rsa-sha256; d=hostedemail.com; s=arc-20220608; cv=none; t=1784129110; b=em4XL+rRlBjCLV6aM/Y7cGL4w7zME/XWCSKX12tTp3poiw8doHAgS/KusrbcH23+LwNUCa /1TzuMCQpphrsgIil26O+OApX2gbbLZYm6WaVYFuleHt8PjYmVtNLJlpY47wA9reryS/lO dUm4920q9vLfmSjZbsZE/NI9Znvgugk= Received: from smtp.kernel.org (quasi.space.kernel.org [100.103.45.18]) by sea.source.kernel.org (Postfix) with ESMTP id D2A2A40DDB; Wed, 15 Jul 2026 15:25:08 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 964801F00A3A; Wed, 15 Jul 2026 15:25:03 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kernel.org; s=k20260515; t=1784129108; bh=qCp0Z/LIk1edhZq1e91Hff3OKVN7JtELVDWP1PDw0J0=; h=Date:From:To:Cc:Subject:References:In-Reply-To; b=VwMy915aEQWDn/J7UuYWhhXw3fAuF/NfHhCeydmjSgm8zTWdGZ07KnFIzAFCGPioU mNxRZH8SV2AisnBrgxf6GmCTn7fXNnVEc+e6DwDNpH8jpvm7hrvgYEc111EpGEewhI 6h1bpyF04jdaupPip8MRN51K+CRQ7yFfolxRDo1qEZeqCY/M/SWy/xLZkfS7kJ4Glg ILmipLdPfluoX0rllpEQL22sWbqsl9tnp7m7OpLfDbSlevM6b2g8JeCQyXT/bMyIg7 OOiSSVscvB13OcUayLrJJSpfisWAiHKVMx1nO7Bc9tqbk0zTWgfwXUf+nUg98nEETe O4cENe7Z0QUYQ== Date: Wed, 15 Jul 2026 16:24:59 +0100 From: Will Deacon To: Lorenzo Stoakes Cc: Andrew Morton , Suren Baghdasaryan , "Liam R. Howlett" , Vlastimil Babka , Shakeel Butt , David Hildenbrand , Mike Rapoport , Michal Hocko , Uladzislau Rezki , Toshi Kani , Dave Hansen , Andy Lutomirski , Peter Zijlstra , Thomas Gleixner , Ingo Molnar , Borislav Petkov , x86@kernel.org, "H. Peter Anvin" , Kiryl Shutsemau , Catalin Marinas , Dev Jain , Ryan Roberts , David Carlier , linux-mm@kvack.org, linux-kernel@vger.kernel.org, bpf@vger.kernel.org, linux-arm-kernel@lists.infradead.org, stable@vger.kernel.org, abarnas@google.com Subject: Re: [PATCH mm-hotfixes v3 2/4] x86/mm/pat: acquire mmap lock on page table free to avoid ptdump UAF Message-ID: References: <20260714-series-vmap-race-fix-v3-0-b812eccfa0f9@kernel.org> <20260714-series-vmap-race-fix-v3-2-b812eccfa0f9@kernel.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20260714-series-vmap-race-fix-v3-2-b812eccfa0f9@kernel.org> X-Stat-Signature: 9bxbontj7yndswcuc949fueuoc8zbi5a X-Rspamd-Queue-Id: EEC0EC0009 X-Rspam-User: X-Rspamd-Server: rspam07 X-HE-Tag: 1784129109-156677 X-HE-Meta: U2FsdGVkX1+5gTCyZIoT24JdtWVBJzA3VFHCTMvaubXUmEhQkKKxESFncr5a+JRDLJAdU4IKh4gplAuTtxJJRiLdpQaLkCnR2+wjg6L1W53c27ZEMe3UDkdEHhMEB6swZ0jSsCCUfOx16zf/JNQmqyb8dIWppEm7HObPVkPX2RY++q1MvHPtbsMeaAOmWZW7ygy/RgOfnEsTA++bDYTQjQKjUogV5XWhrc7pJ0eDOWUjKSMj+kHS/1v68nRr8do/UaPz1w5s3z2t9Wclpbalv5YpqjzLr4YMTYt1PWhpgWRqvMVzP0YyifaF+pnBZ0Gejeru9s612gPY0BJ5KNckHzJbLH9FjH98Y8yAj8Q+QL1SAPLp/7kirHDHI5NqQF7yS61wUyuZcUn6YW2sDGvmz/y1/qkOpEfJhrAE7KgpY9J8nI2mbm334XUbu7IHYmRDsaI+ZbZcgNqvm0Mgpgg+tRBdH+p8g0aQIdzuF8zxbNryIryOOCyWsgQlNhlmWotgowggdBvVUfyQli/d666+2MiqtMdkzguUYx/udR0+uV4Q3YwrGvvAJoZi4GHQ29x6n5iaEaCBn52Q2PV9yv6fddw8W9TvQif8q3nz7ytr8PNNjSjB0ELw3KYvCSZeA7bcL678YesVi7BlpBsxljJVOuvswms5pSZXONoQFiW7C8A7Kqjlt+zEeBVqS22X1vClnGiU7JI1tuzSPihli+kckpRiN8lRULJJGom68TDUUMhPlh4fu/6qvwNxpcXJZN3MkcHHhBL3YXBf8EOvcKh62+g+Q1r7RKPHes0XjX+OOSj37xyW2hwAgOXOQwjVFqm28gvQlE91lP1OX2Kupew+KJTxETldlD4s2K7DKMRG6Vt6hwKhTVpD+AZxFwPIN7Yqm91Z4R0DwMBarstSKJaM4pwyLLUONM5sBzyX0cKf1++Tb69Co+joaU1yRmq73aISIAXxjjohfoJp/80nS7g qdW4gYsI 0aDGfSqboSG9YDHOfJGHqhPveuYo+XloNTNVsvTxfZ+9q7poW7+XJECS7IvVzz/w8/Jq0B+ZqXnZllu3vcwULAMFr22ulr3WqreQRfao5LFtfPOrkVZRwaRHPYXJg9jte1mrM1Wxa6+wndi82HiI4m2h+Yw8zNiUv2rx3oE80Tk5O993tO3oDlLKvYj511ZliVedvjcowwG8T8cVqWzPF/4UQoaGondHGh/BH0ghv59uDEQSzmQnUCnJkmohfiCYbYjouKxKHwIwh5c/TobDrEN1jt22bqYvzbuje65kdYrSTEQ5wLTr8aklEWg== Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: List-Subscribe: List-Unsubscribe: Hi Lorenzo, I'm certainly no x86 expert (quite the opposite!), but I was looking at this with Adrian and got myself confused. See below. On Tue, Jul 14, 2026 at 06:24:24PM +0100, Lorenzo Stoakes wrote: > 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. > > Resolve the issue by acquiring the mmap read lock on init_mm which prevents > a concurrent ptdump as it acquires the write lock. > > 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") > Cc: stable@vger.kernel.org > Reviewed-by: Mike Rapoport (Microsoft) > Reviewed-by: Kiryl Shutsemau (Meta) > Signed-off-by: Lorenzo Stoakes > --- > arch/x86/mm/pat/set_memory.c | 14 +++++++++++--- > 1 file changed, 11 insertions(+), 3 deletions(-) > > diff --git a/arch/x86/mm/pat/set_memory.c b/arch/x86/mm/pat/set_memory.c > index d023a40a1e03..4c4b8244502f 100644 > --- a/arch/x86/mm/pat/set_memory.c > +++ b/arch/x86/mm/pat/set_memory.c > @@ -22,6 +22,7 @@ > #include > #include > #include > +#include > > #include > #include > @@ -436,9 +437,16 @@ static void cpa_collapse_large_pages(struct cpa_data *cpa) > > flush_tlb_all(); > > - list_for_each_entry_safe(ptdesc, tmp, &pgtables, pt_list) { > - list_del(&ptdesc->pt_list); > - pagetable_free(ptdesc); > + /* > + * ptdump might read these page tables, so avoid a use-after-free by > + * acquiring the mmap read lock on init_mm (ptdump acquires the mmap > + * write lock). > + */ > + scoped_guard(mmap_read_lock, &init_mm) { > + list_for_each_entry_safe(ptdesc, tmp, &pgtables, pt_list) { > + list_del(&ptdesc->pt_list); > + pagetable_free(ptdesc); > + } As I understand it, the argument for taking the read lock is that we're operating on a region that we "wholly own" and therefore we can happily run concurrently with CPUs walking distinct parts of the page-table. However, from what I can tell, the CPA collapse logic will operate on regions outside of the address range being manipulated by its caller because it rounds up to the PMD size. As a made-up example, imagine I have a 2MiB aligned region where the first 1MiB is read-only and the second 1MiB is in the default r/w state. If one CPU calls set_memory_rw() on the first 1MiB while another CPU is walking the second 1MiB (via some other API that doesn't take cpa_lock), it looks to me like the first CPU can collapse the page-table and free the unused pages under the feet of the other CPU. What prevents that from happening? If all concurrent walkers have interrupts disabled, I guess the TLB invalidation logic would do it, but it would be good to call this out in the commit message because it's not clear to me why the read_lock is sufficient for the collapsing case. Cheers, Will