Re: [PATCH v3 2/9] riscv: kexec: Bound FDT search by source buffer size, not destination

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:

Pre-existing issues:
- [Critical] In `kexec_file_load`, an attacker can bypass Secure Boot restrictions by providing an initrd that starts with a forged FDT header, overwriting the kernel-constructed FDT.
- [High] The check `if (!internal->fdt_addr)` falsely rejects a valid FDT if it is placed at physical address 0x0.
--

commit 0ee8b0469cc5460085b86fc5826ddc9fa0522c40
Author: Fangyu Yu <fangyu.yu@linux.alibaba.com>

riscv: kexec: Bound FDT search by source buffer size, not destination

This commit changes the FDT size check in machine_kexec_prepare() to use
bufsz instead of memsz. This correctly bounds the read to the provided
source buffer, preventing out-of-bounds reads and potential kernel faults
when a segment is padded with zeros at its destination.

> diff --git a/arch/riscv/kernel/machine_kexec.c b/arch/riscv/kernel/machine_kexec.c
> index ea6794c9f4c2d..e6e179cffc447 100644
> --- a/arch/riscv/kernel/machine_kexec.c
> +++ b/arch/riscv/kernel/machine_kexec.c
> @@ -38,21 +38,21 @@ machine_kexec_prepare(struct kimage *image)
>  
>  	/* Find the Flattened Device Tree and save its physical address */
>  	for (i = 0; i < image->nr_segments; i++) {
> -		if (image->segment[i].memsz <= sizeof(fdt))
> +		if (image->segment[i].bufsz < sizeof(fdt))
>  			continue;
>  
>  		if (image->file_mode)
>  			memcpy(&fdt, image->segment[i].buf, sizeof(fdt));
>  		else if (copy_from_user(&fdt, image->segment[i].buf, sizeof(fdt)))
>  			continue;
>  
>  		if (fdt_check_header(&fdt))
>  			continue;
>  
>  		internal->fdt_addr = (unsigned long) image->segment[i].mem;
>  		break;

[Severity: Critical]
This is a pre-existing issue, but does this blind search loop in
machine_kexec_prepare() allow a user-provided segment to spoof the FDT?

For kexec_file_load, architecture-specific loading adds the user-provided
initrd segment before the kernel-constructed FDT segment. If a malicious
initrd starts with FDT magic bytes, it seems this loop would accept it and
break early.

Would this cause the next kernel to boot using an attacker-controlled FDT
instead of the kernel-generated one? This could allow injection of arbitrary
bootargs (like init=/bin/sh module.sig_enforce=0) and bypass Secure Boot
restrictions.

>  	}
>  
>  	if (!internal->fdt_addr) {

[Severity: High]
This is a pre-existing issue, but could the !internal->fdt_addr check in
machine_kexec_prepare() incorrectly reject a valid FDT if it is placed at
physical address 0x0?

On RISC-V platforms where the physical memory base starts at 0x0 (such as
the T-Head TH1520), the FDT segment can legitimately be loaded at physical
address 0x0. The search loop will correctly set internal->fdt_addr = 0, but
this check would treat it as an error and return -EINVAL.

Is there a risk that this false rejection breaks kexec functionality on
platforms where memory starts at 0x0?

>  		pr_err("Device tree not included in the provided image\n");
>  		return -EINVAL;
>  	}

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260604132418.15725-1-fangyu.yu@linux.alibaba.com?part=2