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 <[email protected]> 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-e511e9ee2...@jaseg.de?part=2
