Hi Breno, On 8/27/25 12:42, Breno Leitao wrote:
The kexec_buf structure was previously declared without initialization. commit bf454ec31add ("kexec_file: allow to place kexec_buf randomly") added a field that is always read but not consistently populated by all architectures. This un-initialized field will contain garbage. This is also triggering a UBSAN warning when the uninitialized data was accessed: ------------[ cut here ]------------ UBSAN: invalid-load in ./include/linux/kexec.h:210:10 load of value 252 is not a valid value for type '_Bool' Zero-initializing kexec_buf at declaration ensures all fields are cleanly set, preventing future instances of uninitialized memory being used. An initial fix was already landed for arm64[0], and this patchset fixes the problem on the remaining arm64 code and on riscv, as raised by Mark. Discussions about this problem could be found at[1][2]. Link: https://lore.kernel.org/all/20250826180742.f2471131255ec1c43683ea07@xxxxxxxxxxxxxxxxxxxx/ [0] Link: https://lore.kernel.org/all/oninomspajhxp4omtdapxnckxydbk2nzmrix7rggmpukpnzadw@c67o7njgdgm3/ [1] Link: https://lore.kernel.org/all/20250826-akpm-v1-1-3c831f0e3799@xxxxxxxxxx/ [2] Signed-off-by: Breno Leitao <leitao@xxxxxxxxxx> --- Breno Leitao (3): arm64: kexec: Initialize kexec_buf struct in load_other_segments() riscv: kexec: Initialize kexec_buf struct s390: kexec: Initialize kexec_buf struct arch/arm64/kernel/machine_kexec_file.c | 2 +- arch/riscv/kernel/kexec_elf.c | 4 ++-- arch/riscv/kernel/kexec_image.c | 2 +- arch/riscv/kernel/machine_kexec_file.c | 2 +- arch/s390/kernel/kexec_elf.c | 2 +- arch/s390/kernel/kexec_image.c | 2 +- arch/s390/kernel/machine_kexec_file.c | 6 +++--- 7 files changed, 10 insertions(+), 10 deletions(-) --- base-commit: 3c642997252eef4449cb6b6e02af3dc22515d817 change-id: 20250827-kbuf_all-b9d55c9291eb Best regards, -- Breno Leitao <leitao@xxxxxxxxxx>
I see that the commit those patches fix is in 6.16 so we should add cc: stable.
And who should merge those patches? Should we do it on a per-arch basis? Thanks, Alex
_______________________________________________ linux-riscv mailing list linux-riscv@xxxxxxxxxxxxxxxxxxx http://lists.infradead.org/mailman/listinfo/linux-riscv