Re: [PATCH 1/6] spl: fit: reject failures loading an explicitly requested FDT

[Carlo Caione <ccaione@baylibre.com>]

On Tue, Nov 03, 2026 at 11:09:31 +0100, Mattijs Korpershoek wrote:
> Hi Carlo,
> 
> Thank you for the patch.
> 
> > A U-Boot image may embed its device tree, but a FIT which explicitly
> > names an FDT must not boot after that FDT fails to load or verify.
> > External FDT data is copied to its load address before verification,
> > so ignoring the error can leave an unverified device tree for U-Boot.
> > 
> > Keep support for U-Boot images without a separate FDT, but reject
> > failures for an explicitly requested FDT in both firmware and loadables.
> > 
> > Fixes: d879616e9e64 ("spl: fit: simplify logic for FDT loading for non-OS boots")
> > Signed-off-by: Carlo Caione <ccaione@baylibre.com>
> >
> > diff --git a/common/spl/spl_fit.c b/common/spl/spl_fit.c
> > index 64e5f95546f1..a520db765065 100644
> > --- a/common/spl/spl_fit.c
> > +++ b/common/spl/spl_fit.c
> > @@ -491,11 +491,14 @@ static int spl_fit_append_fdt(struct spl_image_info *spl_image,
> >  	image_info.load_addr = ALIGN(spl_image->load_addr + spl_image->size, 8);
> >  
> >  	/* Figure out which device tree the board wants to use */
> > +	spl_image->fdt_addr = NULL;
> 
> What's the point of initializing fdt_addr to NULL here?
> It's assigned in both cases (whether node < 0 or not).

We actually have a way out if (node < 0) and (!gd->fdt_blob) and the
problematic path is that early return.

The problem starts in spl_load_simple_fit() where image_info is not
zero-initialized so ->fdt_addr is basically garbage. 

When we return early this garbage is copied into spl_image->fdt_addr.

Even zero-initializing the passed struct doesn't fully solve the issue
because the helper also receives the main spl_image, which is reused
across boot attempts and can contain a stale FDT pointer.

So, setting fdt_addr to NULL is the quickest fix for all the cases.

--
Carlo Caione