Re: [PATCH][next] wifi: wext-core: Fix -Wstringop-overflow warning in ioctl_standard_iw_point()

[Simon Horman]

On Thu, Jun 15, 2023 at 12:04:07PM -0600, Gustavo A. R. Silva wrote:
> -Wstringop-overflow is legitimately warning us about extra_size
> pontentially being zero at some point, hence potenially ending

nit: checkpatch --codespell suggests: potenially -> potentially

> up _allocating_ zero bytes of memory for extra pointer and then
> trying to access such object in a call to copy_from_user().
> 
> Fix this by adding a sanity check to ensure we never end up
> trying to allocate zero bytes of data for extra pointer, before
> continue executing the rest of the code in the function.
> 
> Address the following -Wstringop-overflow warning seen when built
> m68k architecture with allyesconfig configuration:
>                  from net/wireless/wext-core.c:11:
> In function '_copy_from_user',
>     inlined from 'copy_from_user' at include/linux/uaccess.h:183:7,
>     inlined from 'ioctl_standard_iw_point' at net/wireless/wext-core.c:825:7:
> arch/m68k/include/asm/string.h:48:25: warning: '__builtin_memset' writing 1 or more bytes into a region of size 0 overflows the destination [-Wstringop-overflow=]
>    48 | #define memset(d, c, n) __builtin_memset(d, c, n)
>       |                         ^~~~~~~~~~~~~~~~~~~~~~~~~
> include/linux/uaccess.h:153:17: note: in expansion of macro 'memset'
>   153 |                 memset(to + (n - res), 0, res);
>       |                 ^~~~~~
> In function 'kmalloc',
>     inlined from 'kzalloc' at include/linux/slab.h:694:9,
>     inlined from 'ioctl_standard_iw_point' at net/wireless/wext-core.c:819:10:
> include/linux/slab.h:577:16: note: at offset 1 into destination object of size 0 allocated by '__kmalloc'
>   577 |         return __kmalloc(size, flags);
>       |                ^~~~~~~~~~~~~~~~~~~~~~
> 
> This help with the ongoing efforts to globally enable
> -Wstringop-overflow.
> 
> Link: https://github.com/KSPP/linux/issues/315
> Signed-off-by: Gustavo A. R. Silva <gustavoars@xxxxxxxxxx>

Reviewed-by: Simon Horman <simon.horman@xxxxxxxxxxxx>