Thread (5 messages) read the whole thread 5 messages, 4 authors, 2025-08-27

Re: [PATCH] arm64: kexec: Initialize kexec_buf struct in image_load()

From: Breno Leitao <leitao@debian.org>
Date: 2025-08-26 15:26:46
Also in: kexec, lkml

On Tue, Aug 26, 2025 at 03:40:22PM +0100, Mark Rutland wrote:
On Tue, Aug 26, 2025 at 05:08:51AM -0700, Breno Leitao wrote:
quoted
The kexec_buf structure was previously declared without initialization
in image_load(). This led to a UBSAN warning when the structure was
expanded and uninitialized fields were accessed [1].
Just to check my understanding, is that only a problem for new fields
(e.g. the 'random' field added in [1]), or do we have UBSAN warnigns for
any existing fields? I assume there's no problem with existing fields
today.
UBSAN is only complaning for this new field that was added to the
struct, but only populated in x86, later it is read in in common code,
causing UBSAN to complain (and even wrong code to be executed depending
on the garabe that is in the memory during kbuf instantiation.
quoted
Zero-initializing kexec_buf at declaration ensures all fields are
cleanly set, preventing future instances of uninitialized memory being
used.

Andrew Morton suggested that this function is only called 3x a week[2],
thus, the memset() cost is inexpressive.

Link: https://lore.kernel.org/all/oninomspajhxp4omtdapxnckxydbk2nzmrix7rggmpukpnzadw@c67o7njgdgm3/ (local) [1]
Link: https://lore.kernel.org/all/20250825180531.94bfb86a26a43127c0a1296f@linux-foundation.org/ (local) [2]
Suggested-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Breno Leitao <leitao@debian.org>
This looks fine to me, but I reckon it should be added to the series
which extends kexec_buf, unless there's some reason to avoid that?
quoted
---
 arch/arm64/kernel/kexec_image.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)
IIUC arch/arm64/kernel/machine_kexec_file.c would need the same
treatment in load_other_segments().

If other architectures need this, it'd probably make sense to clean that
up treewide in one go. It looks like at least riscv and s390 need that
from a quick grep:
Agree. Let me send a v2 addressing it on all archicterures.
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help