Re: linux-next: build failure after merge of the char-misc tree

[Greg KH <greg@kroah.com>]

On Thu, Jul 03, 2025 at 05:10:21PM +1000, Stephen Rothwell wrote:
> Hi all,
> 
> After merging the char-misc tree, today's linux-next build (x86_64
> allmodconfig) failed like this:
> 
> In file included from include/linux/string.h:392,
>                  from include/linux/bitmap.h:13,
>                  from include/linux/cpumask.h:12,
>                  from arch/x86/include/asm/paravirt.h:21,
>                  from arch/x86/include/asm/irqflags.h:102,
>                  from include/linux/irqflags.h:18,
>                  from include/linux/spinlock.h:59,
>                  from include/linux/wait.h:9,
>                  from include/linux/wait_bit.h:8,
>                  from include/linux/fs.h:7,
>                  from include/linux/highmem.h:5,
>                  from drivers/misc/vmw_vmci/vmci_context.c:10:
> In function 'fortify_memset_chk',
>     inlined from 'ctx_fire_notification.isra' at drivers/misc/vmw_vmci/vmci_context.c:254:3:
> include/linux/fortify-string.h:480:25: error: call to '__write_overflow_field' declared with attribute warning: detected write beyond size of field (1st parameter); maybe use struct_group()? [-Werror=attribute-warning]
>   480 |                         __write_overflow_field(p_size_field, size);
>       |                         ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> cc1: all warnings being treated as errors
> 
> Caused by commit
> 
>   bfb4cf9fb97e ("vmci: Prevent the dispatching of uninitialized payloads")

Ah, nice catch!  Sorry this didn't trigger in my testing.

Yes, it looks like both the code is correct, AND the warning is correct
as the compiler has no idea that you can just scribble off the end of
the structure like this.  In fact I would say the code is wrong as there
could be padding between the two fields that the change doesn't handle
properly (which in reality probably isn't happening).

Lizhi, I'm going to revert this change now, please fix it up "properly"
either by correctly changing the structure definition to show that the
payload is hanging out after the header (and also you can use the
__counted_by mark), or just properly zapping out the payload length in
the proper way instead of doing "fun" pointer math like your change did.

thanks,

greg k-h