On Wed, Apr 20, 2022 at 10:14 AM Johan Hovold johan@kernel.org wrote:
On Mon, Apr 18, 2022 at 09:17:42PM -0700, Kees Cook wrote:
This looks like it's harmless, as both the source and the destinations are currently the same allocation size (4 bytes) and don't use their padding, but if anything were to ever be added after the "mcr" member in "struct whiteheat_private", it would be overwritten. The structs both have a single u8 "mcr" member, but are 4 bytes in padded size. The memcpy() destination was explicitly targeting the u8 member (size 1) with the length of the whole structure (size 4), triggering the memcpy buffer overflow warning:
Ehh... No. The size of a structure with a single u8 is 1, not 4. There's nothing wrong with the current code even if the use of memcpy for this is a bit odd.
In file included from include/linux/string.h:253, from include/linux/bitmap.h:11, from include/linux/cpumask.h:12, from include/linux/smp.h:13, from include/linux/lockdep.h:14, from include/linux/spinlock.h:62, from include/linux/mmzone.h:8, from include/linux/gfp.h:6, from include/linux/slab.h:15, from drivers/usb/serial/whiteheat.c:17: In function 'fortify_memcpy_chk', inlined from 'firm_send_command' at drivers/usb/serial/whiteheat.c:587:4: include/linux/fortify-string.h:328:25: warning: call to '__write_overflow_field' declared with attribute warning: detected write beyond size of field (1st parameter); maybe use struct_group()? [-Wattribute-warning] 328 | __write_overflow_field(p_size_field, size); | ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
So something is confused here.
So something's going wrong in fortify_memcpy_chk()? It looks like it is called with constant "size" equal to 1, and the condition "p_size_field < size" (with an unsigned comparison) is either true (meaning p_size_field would have to be 0) or not known at compile time?
The original report says it happened when compiling with CONFIG_CC_OPTIMIZE_FOR_SIZE=y, maybe that matters?