Hi Gustavo, Apologies for the delay. On Mon, Aug 02, 2021 at 08:46:20AM -0500, Gustavo A. R. Silva wrote: > Hi Sakari, > > On 8/2/21 01:05, Sakari Ailus wrote: > > Hi Gustavo, > > > > I missed you already had sent v2... > > > > On Fri, Jul 30, 2021 at 07:08:13AM -0500, Gustavo A. R. Silva wrote: > >> There is a wrong comparison of the total size of the loaded firmware > >> css->fw->size with the size of a pointer to struct imgu_fw_header. > >> > >> Fix this by using the right operand 'struct imgu_fw_header' for > >> sizeof, instead of 'struct imgu_fw_header *' and turn binary_header > >> into a flexible-array member. Also, adjust the relational operator > >> to be '<=' instead of '<', as it seems that the intention of the > >> comparison is to determine if the loaded firmware contains any > >> 'struct imgu_fw_info' items in the binary_header[] array than merely > >> the file_header (struct imgu_fw_bi_file_h). > >> > >> The replacement of the one-element array with a flexible-array member > >> also help with the ongoing efforts to globally enable -Warray-bounds > >> and get us closer to being able to tighten the FORTIFY_SOURCE routines > >> on memcpy(). > >> > >> Link: https://github.com/KSPP/linux/issues/79 > >> Link: https://github.com/KSPP/linux/issues/109 > >> Fixes: 09d290f0ba21 ("media: staging/intel-ipu3: css: Add support for firmware management") > >> Cc: stable@xxxxxxxxxxxxxxx > >> Signed-off-by: Gustavo A. R. Silva <gustavoars@xxxxxxxxxx> > >> --- > >> > >> It'd be just great if someone that knows this code better can confirm > >> these changes are correct. In particular the adjustment of the > >> relational operator. Thanks! > >> > >> Changes in v2: > >> - Use flexible array and adjust relational operator, accordingly. > > > > The operator was just correct. The check is just there to see the firmware > > is at least as large as the struct as which it is being accessed. > > I'm a bit confused, so based on your reply to v1 of this series, this patch > is now correct, right? > > The operator in v1 _was_ correct as long as the one-element array wasn't > transformed into a flexible array, right? > > Notice that generally speaking flexible-array members don't occupy space in the > containing structure: > > $ pahole -C imgu_fw_header drivers/staging/media/ipu3/ipu3-css-fw.o > struct imgu_fw_header { > struct imgu_fw_bi_file_h file_header; /* 0 72 */ > /* --- cacheline 1 boundary (64 bytes) was 8 bytes ago --- */ > struct imgu_fw_info binary_header[] __attribute__((__aligned__(8))); /* 72 0 */ > > /* size: 72, cachelines: 2, members: 2 */ > /* forced alignments: 1 */ > /* last cacheline: 8 bytes */ > } __attribute__((__aligned__(8))); > > $ pahole -C imgu_fw_header drivers/staging/media/ipu3/ipu3-css-fw.o > struct imgu_fw_header { > struct imgu_fw_bi_file_h file_header; /* 0 72 */ > /* --- cacheline 1 boundary (64 bytes) was 8 bytes ago --- */ > struct imgu_fw_info binary_header[1] __attribute__((__aligned__(8))); /* 72 1200 */ > > /* size: 1272, cachelines: 20, members: 2 */ > /* forced alignments: 1 */ > /* last cacheline: 56 bytes */ > } __attribute__((__aligned__(8))); > > So, now that the flexible array transformation is included in the same patch as the > bugfix, the operator is changed from '<' to '<=' '<' is correct since you only need as much data as the struct you're about to access is large, not a byte more than that. As Dan noted. I think you could add a check for binary_nr is at least one. -- Kind regards, Sakari Ailus
