From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-alma10-1.taild15c8.ts.net [100.103.45.18]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 8E2DA353A64 for ; Fri, 3 Jul 2026 13:01:39 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=100.103.45.18 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1783083700; cv=none; b=j11XFHSF32pDrOJKyazJ7doWTANUnviiyIqR57jCHnXa2vyTVnx3I7xIjh6ajtk+UMhKtUL/94vpjsIdqwEZ/sG0rXJp2OTBhqhrb+0dFfpKA5PIq3icGvEldeW8zHioCdgftJ4FIYRhzx2E49Jmk6rUWO5a4XSU/fGasgjMjIg= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1783083700; c=relaxed/simple; bh=o2HRfKgVA7qq7zCx8q7LBFVxtnwwJ1HatDskJbHhL54=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=oqQhc5q/9Ld4vc3jmUHNftzJIXi/jzYRjF2IaOprxUqfkUwFGw/AvOk8+fH7UcDDniQ6FNsmFiOkAxXbj22pnKFN6OSkbiDhv0Wp2g/yDhJhvMuj3k35pbJ05m8x/QzD7XvLHlF21sn2OR//b22/chxpb3o3n1WcML3CW+4tUdM= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=JeiWBbO0; arc=none smtp.client-ip=100.103.45.18 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="JeiWBbO0" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 701E91F00A3D; Fri, 3 Jul 2026 13:01:38 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kernel.org; s=k20260515; t=1783083699; bh=LzdUtForoTdO80EL0vmwwcBxNLnj1vM9JetvlDMTTNQ=; h=Date:From:To:Cc:Subject:References:In-Reply-To; b=JeiWBbO0rTmeNzG4GCMNPHTTBhPDWh28I/YDYxPOTlwBLb8zPEgvZRRhEE4hWEzuJ IT0aMc9Lh75czM2snIqYptP/cvaCSRQdm28WtNMuJnW3fHoCPNl1gXX3S/bByafoMu TbcbJdr3BCZCYzFYMSr/H/upKyB2kbvbkHLZAEBhgWOCkk5T6gwdW/riauv099T+pv 1OIUex4SIDZRuLJDlztp6h2G4y2vW1ZGjL5NSXsebzlhGD2m6bm+1YXLQ0zv/YFP7e dry6cObjI721QfNpoJqiUQruoAS4TAYgpuiQaGv7DoJIOC8Q8ZRkCcYuJZ1TDKWn2u pZDDf5w0FxxGA== Received: from phl-compute-05.internal (phl-compute-05.internal [10.202.2.45]) by mailfauth.phl.internal (Postfix) with ESMTP id 48B18F40068; Fri, 3 Jul 2026 09:01:37 -0400 (EDT) Received: from phl-frontend-03 ([10.202.2.162]) by phl-compute-05.internal (MEProxy); Fri, 03 Jul 2026 09:01:37 -0400 X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: dmFkZTECIbg+du1baZ9w/Cwr5Wxm0S7Cr3d3Vlz3j2Yk5LU03l+EX+F3w5egh4PmhPHUDV gu5rV+Eeu2I5o/NmjZOTxmwj6ER7BXwhF8ATEu8wGX4qsm1wPm+W8EmWAYX5HTIa754mEN EhWZyEt447jsklEs02mLiT9e4xZfrlfXpVMZmbCXtW1OwGiOYr5lJ9KUqxrrjFf0CRdbwy Il4MPlA1cafd3PoZnp0oZbEvTMpMdN0hE74gbMwl8UstZYBAv/5mEP/sWT7iY9Prn+7TGd NZ5BvoArCaRZVNcnm9wPZ1O8KmrH6GL0k7lzDfwuNyFaHtVU9Z5HvX6XayciweXhydLCRv /sOZ0iUCa7pk4Kfjd+KWlXZ6cqbMH2SUkWCu/hY5QUBbEBv9sY7IL5ojfRdDwKGUst6PLg I7swbSeuOdcztXB666UIk1F5YfYQd5+3IxGI3zxu+lXqm2yFoRRsHzRac5If4ui9Vy6woF Ia/HdKRiYQOnGUFxlXLZt3ewJKrlcpRFv+e5HtgxR8luaTuGRJyxU8Kg5dzs1FPQqSF7XR D/wB7GDLCUBmE/vaQsPAhHb3hpcT1BJKh+Z4xR3NvXxJj5tWtPj+Bqemcp77+tc9/c7FbT NUDmiIX6D2VzBZisxhYEZHhA17XXjQg8Eva1l6QHruT0OyWt6GyckUhvKm1g X-ME-Proxy: Feedback-ID: i10464835:Fastmail Received: by mail.messagingengine.com (Postfix) with ESMTPA; Fri, 3 Jul 2026 09:01:36 -0400 (EDT) Date: Fri, 3 Jul 2026 14:01:35 +0100 From: Kiryl Shutsemau To: "Denis V. Lunev" Cc: Dave Hansen , Andy Lutomirski , Peter Zijlstra , x86@kernel.org, Thomas Gleixner , Ingo Molnar , Borislav Petkov , "H. Peter Anvin" , "Mike Rapoport (Microsoft)" , Juergen Gross , linux-kernel@vger.kernel.org Subject: Re: [PATCH] x86/mm/pat: take cpa_lock around large-page collapse Message-ID: References: <20260626163213.2284080-1-den@openvz.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20260626163213.2284080-1-den@openvz.org> On Fri, Jun 26, 2026 at 06:32:11PM +0200, Denis V. Lunev wrote: > Loading and unloading modules concurrently on several CPUs on a KASAN > build, with a short delay injected at the CPA page-table lookup to > widen the window, faults within minutes: > > BUG: KASAN: use-after-free in __change_page_attr+0x7cc/0x7e0 > Write of size 8 at addr ffff888181139718 by task modprobe > ... > The buggy address belongs to the physical page: > pfn:0x181139 ... page_type: f2(table) > > cpa_collapse_large_pages() rebuilds a leaf PMD from its 4K PTEs and > frees the old PTE-table pages, while __change_page_attr() fetches a > PTE pointer from a lockless lookup_address_in_pgd_attr() and writes > it with set_pte_atomic() only later. When module text is served from > a shared large ROX mapping the two run on the same PMD: > > CPU A (module load) CPU B (module finalize) > ------------------- ----------------------- > execmem_make_temp_rw > set_memory_nx > __change_page_attr > split 2M -> 4K table P > kpte = &P[i] (lockless) > execmem_restore_rox > set_memory_rox (CPA_COLLAPSE) > cpa_collapse_large_pages > rebuild leaf PMD > flush_tlb_all > pagetable_free(P) > set_pte_atomic(kpte, ...) > -> writes into freed P > > P is a page-table page (page_type: table), reused at once, so the > write corrupts whatever got the page next: a bad-pte or bad-page > splat, or a fatal fault once P has been turned into read-only text. > > The flush_tlb_all() before the free does not close this: its IPI only > serializes against page-table walkers that run with interrupts off > (e.g. GUP-fast); the walk in __change_page_attr() runs with interrupts > on, so nothing stops it from holding a stale pointer into P. > > Serialize the collapse - the PMD rebuild, TLB flush and PTE-table > free - under cpa_lock, the lock __change_page_attr() takes for the > split path, so a concurrent walker can no longer hold a pointer into > a table the collapse is about to free. > > debug_pagealloc bypasses cpa_lock in __change_page_attr() (the direct > map is 4K then, with no large pages to serialize), so the lock cannot > order the two there. Skip the collapse in that config: it is only an > optimization, and not freeing the tables leaves the unserialized walk > nothing to race. > > Fixes: 41d88484c71c ("x86/mm/pat: restore large ROX pages after fragmentation") > Signed-off-by: Denis V. Lunev Acked-by: Kiryl Shutsemau (Meta) -- Kiryl Shutsemau / Kirill A. Shutemov