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 6F9DA34F27B for ; Sun, 5 Jul 2026 20:31:31 +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=1783283492; cv=none; b=OmSzi8Z/0IXksyg3vNxPHS08s5RJbg3CjOsGhcu9ZrpS59PAZuP8iOSCxV7PfEw1Df+iKbfwU2+KBVhaUGG0mMy7U8BYIHk8xSJX+Nqcq5ApYoTlADwUXHrOZzZEa0f5viXiV7yATpRfSbkukZ7tYn4t8TVmVcI+7xi7nJn7HI4= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1783283492; c=relaxed/simple; bh=ERXPq4Ox6vXqEP4D6457UR4DmY1zbqvWv/yRjkVJIWc=; h=Date:From:To:Cc:Subject:Message-Id:In-Reply-To:References: Mime-Version:Content-Type; b=OIsQMN79fiI2Gg8n7UBQzqNYDSG/gyZ+g6sXPUwXeJfHhdgAJBr1V9ckFaLtSMQhr/z+0WEITux/m1Dbr4N+pC47nDA15DeR9bjJUNEd8udNGlX1X4LuARvzTeKTPPV7wjCXMQHBUeDIH1qqwoZqnsj2DL0rO77JOg/2yRw5CWM= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=linux-foundation.org header.i=@linux-foundation.org header.b=Mn3IM1gO; arc=none smtp.client-ip=100.103.45.18 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=linux-foundation.org header.i=@linux-foundation.org header.b="Mn3IM1gO" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 5CBB61F000E9; Sun, 5 Jul 2026 20:31:30 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux-foundation.org; s=korg; t=1783283490; bh=Z/shfTy2/IJB2wTTprOVJQY6HZudzX/XlXY2dxUeOSc=; h=Date:From:To:Cc:Subject:In-Reply-To:References; b=Mn3IM1gOLuSx2CRIiw/WJHtJAo+egenKF8r82+OKr1WK+mLooaPGmNHINMAcwIXy0 5RFYgz2anWpmLvlH8Uf1hzQqxuNHCsyenTiSr87fB0mgdUFVglqB3KlQyPK5j6iqPB YpA/2dzxBAqYR1+PIglQSO/nkrdxSjTSYWIleauQ= Date: Sun, 5 Jul 2026 13:31:29 -0700 From: Andrew Morton To: David Carlier Cc: Dev Jain , David Hildenbrand , Lorenzo Stoakes , "Liam R . Howlett" , Vlastimil Babka , Mike Rapoport , Suren Baghdasaryan , Michal Hocko , Paul Walmsley , Palmer Dabbelt , Albert Ou , Alexandre Ghiti , Dave Hansen , Lu Baolu , syzbot+fd95a72470f5a44e464c@syzkaller.appspotmail.com, linux-mm@kvack.org, linux-kernel@vger.kernel.org, linux-riscv@lists.infradead.org Subject: Re: [PATCH v7] mm: pgtable: free kernel page tables via RCU to fix ptdump UAF Message-Id: <20260705133129.74b3bf92ed21c9bcddaf6174@linux-foundation.org> In-Reply-To: <20260702093011.336036-1-devnexen@gmail.com> References: <20260702093011.336036-1-devnexen@gmail.com> X-Mailer: Sylpheed 3.8.0beta1 (GTK+ 2.24.33; x86_64-pc-linux-gnu) 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-Transfer-Encoding: 7bit On Thu, 2 Jul 2026 10:30:11 +0100 David Carlier wrote: > ptdump_walk_pgd() walks the kernel page tables under get_online_mems(). > That does not stop vmalloc from freeing a kernel PTE page underneath the > walk. > > When vmap_try_huge_pmd() promotes a range to a huge PMD it collapses the > existing PTE table and frees it via pmd_free_pte_page(). On x86, riscv and > powerpc this runs without the init_mm mmap lock; only arm64 takes it, and > not on the block-split path. So ptdump can dereference a just-freed PTE > page, which is the use after free syzbot hit in ptdump_pte_entry(). > > The race is not new. ptdump walks the whole kernel address space, including > ranges other code is actively mapping, so it reads page tables it does not > own. 5ba2f0a15564 ("mm: introduce deferred freeing for kernel page tables") > only widened the window; the Fixes tag points there for that reason. > > Every other walker works on a range it owns and is the only one mutating > it: set_memory() on arm64/riscv/loongarch, the arm64 block-split path, the > openrisc DMA path and the hugetlb_vmemmap remap. Nothing frees those ranges > concurrently, so they cannot race and do not need RCU. ptdump is the only > walker that traverses ranges it does not own. > > Defer the free by an RCU grace period. pagetable_free_kernel() now frees > via call_rcu() in both the async and non-async configs. The async path > still flushes the TLB first, then queues the per-page RCU free. The page > stays valid until any walk that may have observed it drops its RCU read > lock. Thanks. A use-after-free is something we should attend to! AI review had some thoughts, but in a strange manner: https://sashiko.dev/#/patchset/20260702093011.336036-1-devnexen@gmail.com