[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Message-Id: <20250826-akpm-v1-1-3c831f0e3799@debian.org>
Date: Tue, 26 Aug 2025 05:08:51 -0700
From: Breno Leitao <leitao@...ian.org>
To: Catalin Marinas <catalin.marinas@....com>,
Will Deacon <will@...nel.org>, kexec@...ts.infradead.org
Cc: linux-arm-kernel@...ts.infradead.org, linux-kernel@...r.kernel.org,
bhe@...hat.com, linux-arm-kernel@...ts.infradead.org, oxu@...hat.com,
berrange@...hat.com, kernel-team@...a.com,
Andrew Morton <akpm@...ux-foundation.org>, Breno Leitao <leitao@...ian.org>
Subject: [PATCH] arm64: kexec: Initialize kexec_buf struct in image_load()
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].
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/ [1]
Link: https://lore.kernel.org/all/20250825180531.94bfb86a26a43127c0a1296f@linux-foundation.org/ [2]
Suggested-by: Andrew Morton <akpm@...ux-foundation.org>
Signed-off-by: Breno Leitao <leitao@...ian.org>
---
arch/arm64/kernel/kexec_image.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm64/kernel/kexec_image.c b/arch/arm64/kernel/kexec_image.c
index 532d72ea42ee8..b70f4df15a1ae 100644
--- a/arch/arm64/kernel/kexec_image.c
+++ b/arch/arm64/kernel/kexec_image.c
@@ -41,7 +41,7 @@ static void *image_load(struct kimage *image,
struct arm64_image_header *h;
u64 flags, value;
bool be_image, be_kernel;
- struct kexec_buf kbuf;
+ struct kexec_buf kbuf = {};
unsigned long text_offset, kernel_segment_number;
struct kexec_segment *kernel_segment;
int ret;
---
base-commit: 7a77c6b5ce68a71b9102760a988a4564ff6d4106
change-id: 20250826-akpm-18a57e3a39fd
Best regards,
--
Breno Leitao <leitao@...ian.org>
Powered by blists - more mailing lists