Re: [PATCH v3 02/12] lib, kexec: Add a secret pool for key material

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [High] lib/secret_pool: fallback to shared kmalloc inadvertently marks entire pages as secret
--

commit 774a436bfd0576d919ce17b831096d5b8c8dbbb5
Author: Jan Sebastian Götte <linux@jaseg.de>

lib, kexec: Add a secret pool for key material
    
Key material allocated with kmalloc() shares its slab pages with
unrelated allocations. crash_memaction marks memory at page granularity,
so smaller objects in shared slab pages can't cleanly be marked or
unmarked. This commit adds a secret pool built on kmem_buckets to
hold such keys in marked pages.

> diff --git a/lib/secret_pool.c b/lib/secret_pool.c
> new file mode 100644
> index 0000000000000..62954847091a0
> --- /dev/null
> +++ b/lib/secret_pool.c
> @@ -0,0 +1,27 @@
[ ... ]
> +void *secret_pool_alloc_node(size_t size, gfp_t flags, int node)
> +{
> +	void *p = kmem_buckets_alloc_node_track_caller(secret_pool, size,
> +						       flags, node);
> +
> +	crash_memaction_mark(p, size, CRASH_MEMACTION_SECRET);
        ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

[Severity: High]
Does this unconditionally mark the allocation even if it falls back to a shared
kmalloc page?

The commit message notes that if the secret pool is used before its initcall
runs or if pool creation fails, allocations will fall back to ordinary kmalloc
caches.

Because crash_memaction_mark() operates at page granularity, wouldn't calling
it on a shared kmalloc page inadvertently mark the entire page (and unrelated
kernel objects sharing it) as a secret?

In the event of a crash, could this cause the kdump kernel to wipe or exclude
these shared pages, potentially destroying crash data?

> +
> +	return p;
> +}
> +EXPORT_SYMBOL_GPL(secret_pool_alloc_node);

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260928-crash-memaction-upstream-20260921-v3-0-e511e9ee2329@jaseg.de?part=2