Hi Nikita, On 11/3/26 01:53, Nikita Shubin wrote: > The next patch makes spl_load_fit_image() check spl_image->fdt_addr and
What is "The next patch" is it this patch? or the next one that is not this one... confusing. The whole description could instead be "Zero-initialize spl_image_info on the stack in preparation for any writes to spl_image->fdt_addr" or however this is. The "next" patch will appear in git history and explain further. > write the loadables into that FDT. With an uninitialised spl_image_info > on the stack this could end up writing to a random address. > > Use memset() to make sure spl_image_info is initialised before passing > it, as board_init_r() does. > > Signed-off-by: Nikita Shubin <[email protected]> > --- > test/image/spl_load_os.c | 2 ++ > 1 file changed, 2 insertions(+) > > diff --git a/test/image/spl_load_os.c b/test/image/spl_load_os.c > index ba9d7979a09..e2b55d66394 100644 > --- a/test/image/spl_load_os.c > +++ b/test/image/spl_load_os.c > @@ -15,6 +15,7 @@ static int spl_test_load(struct unit_test_state *uts) > struct spl_image_info image; > char fname[256]; > > + memset(&image, 0, sizeof(image)); > ut_assertok(sandbox_spl_load_fit(fname, sizeof(fname), &image)); > > return 0; > @@ -26,6 +27,7 @@ static int spl_test_load_fit_full(struct unit_test_state > *uts) > struct spl_image_info image; > char fname[256]; > > + memset(&image, 0, sizeof(image)); > ut_assertok(sandbox_spl_load_fit_full(fname, sizeof(fname), &image)); > > return 0; > -E
