Re: [PATCH v3 03/12] mm: Wire up the crash memaction registry

[sashiko-bot]

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 <linux@xxxxxxxx>

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-e511e9ee2329@xxxxxxxx?part=3