Re: [PATCH] MIPS: boot/compressed: Use array reference for image bounds

[Thomas Bogendoerfer <tsbogend@alpha.franken.de>]

On Wed, Mar 09, 2022 at 10:50:32AM -0800, Kees Cook wrote:
> As done with other image addresses in other architectures, use an
> explicit flexible array instead of "address of char", which can trip
> bounds checking done by the compiler. Found when building with
> -Warray-bounds:
> 
> In file included from ./include/linux/byteorder/little_endian.h:5,
>                  from ./arch/mips/include/uapi/asm/byteorder.h:15,
>                  from ./arch/mips/include/asm/bitops.h:21,
>                  from ./include/linux/bitops.h:33,
>                  from ./include/linux/kernel.h:22,
>                  from arch/mips/boot/compressed/decompress.c:13:
> arch/mips/boot/compressed/decompress.c: In function 'decompress_kernel':
> ./include/asm-generic/unaligned.h:14:8: warning: array subscript -1 is outside array bounds of 'unsigned char[1]' [-Warray-bounds]
>    14 |  __pptr->x;        \
>       |  ~~~~~~^~~
> ./include/uapi/linux/byteorder/little_endian.h:35:51: note: in definition of macro '__le32_to_cpu'
>    35 | #define __le32_to_cpu(x) ((__force __u32)(__le32)(x))
>       |                                                   ^
> ./include/asm-generic/unaligned.h:32:21: note: in expansion of macro '__get_unaligned_t'
>    32 |  return le32_to_cpu(__get_unaligned_t(__le32, p));
>       |                     ^~~~~~~~~~~~~~~~~
> arch/mips/boot/compressed/decompress.c:29:37: note: while referencing '__image_end'
>    29 | extern unsigned char __image_begin, __image_end;
>       |                                     ^~~~~~~~~~~
> 
> Cc: Thomas Bogendoerfer <tsbogend@alpha.franken.de>
> Cc: Randy Dunlap <rdunlap@infradead.org>
> Cc: linux-mips@vger.kernel.org
> Signed-off-by: Kees Cook <keescook@chromium.org>
> ---
>  arch/mips/boot/compressed/decompress.c | 10 +++++-----
>  1 file changed, 5 insertions(+), 5 deletions(-)

applied to mips-next.

Thomas.

-- 
Crap can work. Given enough thrust pigs will fly, but it's not necessarily a
good idea.                                                [ RFC1925, 2.3 ]