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 hugetlb folios --
commit 62d401cf60aea442c3fea654492895fe956cadd9 Author: Jan Sebastian Götte <[email protected]> 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_exact(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=0 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; > } -- Sashiko AI review · https://sashiko.dev/#/patchset/20260928-crash-memaction-upstream-20260921-v3-0-e511e9ee2...@jaseg.de?part=3
