[PATCH 1/1] cmd: fdt: check fdt address

[Tom Rini]

On Thu, Dec 21, 2023 at 01:00:11AM +0100, Heinrich Schuchardt wrote:

> Trying to read a device-tree from an illegal address leads to a crash.
> 
> Check that the parameter passed to 'fdt addr' is within the RAM area and
> non-zero.
> 
> Signed-off-by: Heinrich Schuchardt <heinrich.schuchardt at canonical.com>
> ---
>  cmd/fdt.c | 5 +++++
>  1 file changed, 5 insertions(+)
> 
> diff --git a/cmd/fdt.c b/cmd/fdt.c
> index 331564c13b..dc954ea7d5 100644
> --- a/cmd/fdt.c
> +++ b/cmd/fdt.c
> @@ -193,6 +193,11 @@ static int do_fdt(struct cmd_tbl *cmdtp, int flag, int argc, char *const argv[])
>  		}
>  
>  		addr = hextoul(argv[0], NULL);
> +		if (!addr || addr < gd->ram_base || addr >= gd->ram_top) {
> +			printf("Invalid address\n");
> +			return CMD_RET_FAILURE;
> +		}
> +
>  		blob = map_sysmem(addr, 0);
>  		if ((quiet && fdt_check_header(blob)) ||
>  		    (!quiet && !fdt_valid(&blob)))

As I mentioned on IRC, we don't sanity check addresses being within
memory normally. The problem (and one that is making me cranky) is that
it seems a number of RISC-V platforms have invalid kernel/fdt/initrd
addresses set in the environment and then have PREBOOT used to fix
fdt_addr_r so that distro_bootcmd doesn't blow up.

-- 
Tom
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 659 bytes
Desc: not available
URL: <https://lists.denx.de/pipermail/u-boot/attachments/20231221/a3632bd7/attachment.sig>