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 D180F37DE89 for ; Mon, 13 Jul 2026 13:32:12 +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=1783949533; cv=none; b=H+GNVWOZ/wTCnL1SEqiCWjzDXFjrpwzXpcazgwtxbgUVk5F/4LGcl5EFln4b60F2CIZYT5jVCnyC/zA97uqsMP73AmDLbFw2cLSiNdkd9Gku0JED2PS0K9DvRz/MWbpsv6sZPGnfg2heW6LhI/G6WicHIBJRMHpLFEcv0Gy74OA= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1783949533; c=relaxed/simple; bh=RMBNf0nz6UqVKObHbtRoALMqXm0jYPaVeg/zELKfVqI=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=CUC1LgUF+JizTmoFLjUk1TutP1IrGuJ3R8Vz8OtUj8eOGoXX9pKjcrh6QYQgNwvZs4ieu+FmQ6m9ewNx1vWZbIqb/o396pxDDO3QWlKQEjKZ7dRP/JQTkkLv15TZdKuKGTiMvWGBOZetaP/rn0N+lyXsERNUgUKzSr3HO9O9Bl8= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=HaxJIDin; 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="HaxJIDin" Received: by smtp.kernel.org (Postfix) with ESMTPSA id DE2D11F00A3D; Mon, 13 Jul 2026 13:32:11 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kernel.org; s=k20260515; t=1783949532; bh=HebesSjqW6Ei186xyy2KHgsVFXclOSjyLdpPX4+hId0=; h=Date:From:To:Cc:Subject:References:In-Reply-To; b=HaxJIDinBW7qhd8TWrNK4s8T3PTUfLTXFXS85kDKWcN4pWvtuL6xy0nsCIx7iq40O QxcAYjybAjwroqbFOs9TRta3swb5bYhfKBvWawcyqH0Zge2Lx6VdtiZhiBafycuXNH i4/Vlvk4FSU2fyS8bhx8BrQr4NQvM3DRQrVhBKQMkp91hb5Fa4g7Pw14ueQNVgVdTi /h2k/N+9tWkQ4UDofeftbfgEXnxzcX8poyxZ4F8EiUKIMqeXWUW1W0KUWktE6mpRmX RGfWv776A9M5DdWrONyX3UluBAo//ouIVD4GlnqfJmLYmgxG+cxXo7deuEwlEEEjCb MiFOa9IU3UB2A== Received: from phl-compute-04.internal (phl-compute-04.internal [10.202.2.44]) by mailfauth.phl.internal (Postfix) with ESMTP id DF046F40119; Mon, 13 Jul 2026 09:32:10 -0400 (EDT) Received: from phl-frontend-03 ([10.202.2.162]) by phl-compute-04.internal (MEProxy); Mon, 13 Jul 2026 09:32:10 -0400 X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: dmFkZTGZpmVpeDsjZ8Vo2Jq64/2U20HFa/JrgfKn6CiNifuBo1pzPMXk0a4NqT0VMciG8K SugdcXNhzIz2GGRAcNPbldLn+3yx1gRLwC0eqh8SjcuMzzoyAOiQcW15pHkFoUU8sU93Ol 20upXRjRc9bBvKSvF+ldu18a4Su7mlFUTAvgOHmfQ4EOLFyHDZ9CXRB5B0cLlRIRNNuJ69 LDPcIZFQurDXONw9w7x2l+i30vbvXOnao60OZfbfVAcAC/fcUzZNKRbLUxuPN7zU2u+h2L lu3b55TVWwqQsO6vcM7WnlDCmGUWatjBJ4CSoYLZcP+x21iYiTGDYJ0lfqOuP9kAzP2JPg j8w8DwhG5wOdhN2Rk3Rdg8n9nLNaujJTGC620J5zoH7n5t3hX39aCaLsRBN9JGDO7mcmWL IzaLYY9N+V442PvDjYSTXuP4EHvI6v+fcV6Q/yTDaPZDQgnHPe1yyzGNJzxCUjaYKCCdpO z/OkCkLFvQT3MiYbDmeWq3a8qm4Z/Agi5IGGkB4PZs8GgeaaaXu1uHQ/ufm4VZ9+64V+QE 8QtfNFMPv+xm7WYMT9O2psU2UIaozivzoRxbp2UTRKG5DvsMUoVZyOCnD4i8d0NJq/Rqe9 jTIL8srd7T6/FERCHRYF/A9blfowGsOrxRZc+ML2aNnL8IwcxIqNnPaId1jw X-ME-Proxy: Feedback-ID: i10464835:Fastmail Received: by mail.messagingengine.com (Postfix) with ESMTPA; Mon, 13 Jul 2026 09:32:09 -0400 (EDT) Date: Mon, 13 Jul 2026 14:32:09 +0100 From: Kiryl Shutsemau 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" , Catalin Marinas , Will Deacon , 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, syzbot+fd95a72470f5a44e464c@syzkaller.appspotmail.com Subject: Re: [PATCH mm-hotfixes v2 0/4] mm: fix UAF caused by race between ptdump and vmap pgtable freeing Message-ID: References: <20260712-series-vmap-race-fix-v2-0-ad134cc3a12a@kernel.org> Precedence: bulk X-Mailing-List: bpf@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: <20260712-series-vmap-race-fix-v2-0-ad134cc3a12a@kernel.org> On Sun, Jul 12, 2026 at 11:42:23AM +0100, Lorenzo Stoakes wrote: > This series addresses the issue by having the vmap huge promotion > logic acquire the mmap read lock while both setting the huge page > table entry and freeing the prior leaf page table. Hi Lorenzo, Before we settle on the mmap lock scheme, have you considered handling this the way GUP-fast handles page table freeing -- RCU-defer the free and make ptdump a lockless walker? The locking here is inverted from what one would normally expect (walker takes the write lock, mutators take read locks, mutators safe against each other only by range ownership). It works, but it is subtle, it is what produced the arm64 deadlock and the ifdeffery, and it depends on every current and future freeing site remembering the rule -- patch 3 exists because two walkers did not fit the scheme. The free side looks cheap: kernel page table freeing already funnels through pagetable_free_kernel(), which already has a deferred path (used for IOMMU SVA). Adding a grace period there -- synchronize_rcu() in the worker, amortized over the batch -- covers every freeing site by construction. On the walk side, nothing on the ptdump path can sleep -- the pagewalk core only allocates for install_pte ops, kernel PTE level uses pte_offset_kernel(), and the arch note_page() implementations are seq_printf()/printk() into a preallocated buffer. So the walk could run under rcu_read_lock() as is. The real work is bounding the read-side sections: a full walk can take dozens of seconds on a KASAN kernel per the comment in mm/ptdump.c, so it would need to drop RCU and cond_resched() periodically, re-descending from the top. Note we currently hold the init_mm mmap write lock across those same dozens of seconds, and this series makes that load-bearing: during a long walk every promotion trylock fails, silently degrading vmalloc to small pages, and CPA collapse blocks. That would give us: no inverted locking, no arm64 deadlock possibility (your patch 4 stands on its own), the patch 3 walkers covered structurally rather than by locking init_mm as well, and ptdump invisible to production paths. Given the live UAF, this could also be a follow-up rather than a respin. But I would like to hear whether you see a fatal flaw in the approach first. -- Kiryl Shutsemau / Kirill A. Shutemov