From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (prime256v1) server-digest SHA256) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id EF801606A31C for ; Tue, 20 Oct 2026 08:21:46 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key, unprotected) header.d=lists.infradead.org header.i=@lists.infradead.org header.a=rsa-sha256 header.s=bombadil.20210309 header.b=ZifAw3Kg; dkim=pass (2048-bit key, unprotected) header.d=kernel.org header.i=@kernel.org header.a=rsa-sha256 header.s=k20260515 header.b=Gq48WQDi DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20210309; h=Sender:Reply-To:List-Subscribe: List-Help:List-Post:List-Archive:List-Unsubscribe:List-Id:Message-Id:Date: Content-Transfer-Encoding:Content-Type:References:In-Reply-To:Cc:To:Subject: From:MIME-Version:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Owner; bh=XQwrxz5DxAOSOS9tl6JASwUQOclPkIJdyJDy+q6eIS8=; b=ZifAw3KgmDxSve1A63CjHujcmk IIOkQ4VM7LuRmPeYGYaLBbo/Fdmfn6oxn6G9oh3EHqi5bupek90spjpUaGoNH2sqXFkrR6+F1XHwC rClrzUNpG6M7JCObZk41rnBULrBfoBJ3W5rG3MBj/hQ0NoDIXrd8gEp2ITaSXK5l4f3JMXxl5Eaj1 yzrDsweRqPgIqhgfypJUx3Jnd0gR0mIsLSLT8Y789cm0b7AqYxUxshfEYFXAzlvwFjogZvOwNgtiD hN98gONG+gZLZGLB1WAHERYQdGhgqG5YWWgjPwz5o8H48z9XBhRt7oLiyDv3oiTmkb3EXoka2ooIP ntcsPkPw==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.99.1 #2 (Red Hat Linux)) id 1xJ56P-000000099cR-1Wih; Tue, 20 Oct 2026 08:21:45 +0000 Received: from tor.source.kernel.org ([172.105.4.254]) by bombadil.infradead.org with esmtps (Exim 4.99.1 #2 (Red Hat Linux)) id 1xBFJ8-00000001Bs0-1aiS; Mon, 28 Sep 2026 17:38:30 +0000 Received: from smtp.kernel.org (quasi.space.kernel.org [100.103.45.18]) by tor.source.kernel.org (Postfix) with ESMTP id 7F2B7601EF; Mon, 28 Sep 2026 17:38:29 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 79D2B1F000FF; Mon, 28 Sep 2026 17:38:25 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kernel.org; s=k20260515; t=1790617109; bh=XQwrxz5DxAOSOS9tl6JASwUQOclPkIJdyJDy+q6eIS8=; h=From:Subject:Reply-To:To:Cc:In-Reply-To:References:Date; b=Gq48WQDii6Y2wXwqk2Dl5BFMHy7xKx8TTGraKfDWphG9muDmzzP3BKh9CjmfaLF3b OGISBa4ZzYAkBhG9XfSWCUruhzX8uzuilGXlekZydznqvNfrHD6aMMPjaFLjnJiqvv RS0BJPSDgMDpCXRjmHgUqyuIVax/AU7gXUFbYIKly2dx7CBfFuJMxfvmYz+ffoS2uo iQcT5DQH44SZc0420Lhot1F8XmVL3de4jo5/eFDKxyEydTB6dleUSgAgMjplshTKNs z7HPMxwt4Jj4/m6ojc0dHEtXTm0zh80Jt2ohM7T5bFSATpMbyO4Q9pIhcs2aP1aCif ZFYMCktn4VFEw== From: sashiko-bot@kernel.org Subject: Re: [PATCH v3 03/12] mm: Wire up the crash memaction registry To: "Jann Horn" , "Nico Pache" , "Pratyush Yadav" , "Zi Yan" , "Lance Yang" , "Baoquan He" , "Harry Yoo" , "David Hildenbrand" , "Mike Rapoport" , "Greg Kroah-Hartman" , "Usama Arif" , "Kiryl Shutsemau" , "Gregory Price" , "Arnd Bergmann" , "Baolin Wang" , "Serge E. Hallyn" , =?utf-8?b?SmFuIFNlYmFzdGlhbiBHw7Z0dGU=?= , "Catalin Marinas" , "Ying Huang" , "Lorenzo Stoakes" , "Randy Dunlap" , "Muchun Song" , "Pedro Falcato" , "Barry Song" , "Peter Xu" , "Herbert Xu" , "Liam R. Howlett" , "Matthew Brost" , "Alistair Popple" , "Alasdair Kergon" , "Rob Herring" , "Mark Rutland" , "Oscar Salvador" , "Benjamin Marzinski" , "Suren Baghdasaryan" , "Jarkko Sakkinen" , "Rik van Riel" , "Rafael J. Wysocki" , "Johannes Weiner" , "Dave Young" , "Mikulas Patocka" , "Byungchul Park" , "David S. Miller" , "Saravana Kannan" , "Danilo Krummrich" , "Mike Snitzer" , "Michal Hocko" , "Mimi Zohar" , "Paul Moore" , "James Morris" , "Pasha Tatashin" , "Will Deacon" , "James Bottomley" , "Ryan Roberts" , "Dev Jain" , "Joshua Hahn" , "Andrew Morton" , "Brendan Jackman" , "Vlastimil Babka" , "David Howells" , "Shuah Khan" , "Jonathan Corbet" Cc: linux-security-module@vger.kernel.org, linux-doc@vger.kernel.org, linux-integrity@vger.kernel.org, "Eric Biggers" , linux-kernel@vger.kernel.org, keyrings@vger.kernel.org, linux-fsdevel@vger.kernel.org, devicetree@vger.kernel.org, linux-crypto@vger.kernel.org, linux-arm-kernel@lists.infradead.org, driver-core@lists.linux.dev, linux-mm@kvack.org, linux-arch@vger.kernel.org, kexec@lists.infradead.org, robh@kernel.org, dm-devel@lists.linux.dev, conor+dt@kernel.org In-Reply-To: <20260928-crash-memaction-upstream-20260921-v3-3-e511e9ee2329@jaseg.de> References: <20260928-crash-memaction-upstream-20260921-v3-0-e511e9ee2329@jaseg.de> <20260928-crash-memaction-upstream-20260921-v3-3-e511e9ee2329@jaseg.de> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Date: Mon, 28 Sep 2026 17:38:25 +0000 Message-Id: <20260928173825.79D2B1F000FF@smtp.kernel.org> X-Mailman-Approved-At: Tue, 20 Oct 2026 01:21:10 -0700 X-BeenThere: kexec@lists.infradead.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: List-Archive: List-Post: List-Help: List-Subscribe: , Reply-To: sashiko-reviews@lists.linux.dev Sender: "kexec" X-Spam-Status: No, score=-11.2 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF, HEADER_FROM_DIFFERENT_DOMAINS,INCLUDES_PATCH,MAILING_LIST_MULTI, SPF_HELO_NONE,SPF_PASS autolearn=ham autolearn_force=no version=4.0.1 X-Spam-Checker-Version: SpamAssassin 4.0.1 (2024-03-26) on aws-us-west-2-korg-listserv-alma10-1 X-Archived-By: Thank you for your contribution! Sashiko AI review found 1 potential issue(= s) to consider: - [High] mm: Stale secret data exposed due to premature unmarking of hugetl= b folios -- commit 62d401cf60aea442c3fea654492895fe956cadd9 Author: Jan Sebastian G=C3=B6tte mm: Wire up the crash memaction registry This commit allocates the crash memaction registry bitmap during boot and syncs marked pages to it. It introduces hooks to unmark pages when they are handed out, placing the unmark after zeroing for page allocator folios, and in dequeue_hugetlb_folio_node_exact for hugetlb folios. > diff --git a/mm/hugetlb.c b/mm/hugetlb.c > index da980377d3533..36f0c0d8f5f14 100644 > --- a/mm/hugetlb.c > +++ b/mm/hugetlb.c [ ... ] > @@ -1281,6 +1282,9 @@ static struct folio *dequeue_hugetlb_folio_node_exa= ct(struct hstate *h, > folio_clear_hugetlb_freed(folio); > h->free_huge_pages--; > h->free_huge_pages_node[nid]--; > + > + crash_memaction_unmark_pfns(folio_pfn(folio), > + folio_nr_pages(folio)); [Severity: High] Can this expose stale secret data to a crash dump if a crash occurs before the folio is zeroed? When a hugetlb folio containing secret data is freed to the hugetlb pool, it retains its crash_memaction mark. When dequeued here in dequeue_hugetlb_folio_node_exact(), it is unconditionally unmarked before being returned. Because the caller is responsible for zeroing the folio later via folio_zero_user(), a window exists where the kdump kernel could observe an unmarked folio and include its unzeroed secret data in the dump. (Note: A similar window appears to exist for THP allocations when init_on_alloc=3D0 because THP is allocated without __GFP_ZERO, causing post_alloc_hook() to unmark it before the fault handler zeroes it.) Could this unmarking be delayed until after the folio is zeroed? > return folio; > } --=20 Sashiko AI review =C2=B7 https://sashiko.dev/#/patchset/20260928-crash-mema= ction-upstream-20260921-v3-0-e511e9ee2329@jaseg.de?part=3D3