On 10/1/19 5:36 PM, David Laight wrote:
From: Dan Carpenter Sent: 01 October 2019 14:57 Subject: Re: [PATCH] staging: rtl8723bs: hal: Fix memcpy calls
...
That's true for glibc memcpy() but not for the kernel memcpy(). In the kernel there are lots of places which do a zero size memcpy().
And probably from NULL (or even garbage) pointers.
After all a pointer to the end of an array (a + ARRAY_SIZE(a)) is valid but must not be dereferenced - so memcpy() can't dereference it's source address when the length is zero.
The glibc attitude is "the standard allows us to put knives here" so let's put knives everywhere in the path. And the GCC attitude is let's silently remove NULL checks instead of just printing a warning that the NULL check isn't required... It could really make someone despondent.
gcc is the one that add knives...
Just found an official documentation to this issue: https://gcc.gnu.org/gcc-4.9/porting_to.html "Null pointer checks may be optimized away more aggressively ... The pointers passed to memmove (and similar functions in <string.h>) must be non-null even when nbytes==0, so GCC can use that information to remove the check after the memmove call. Calling copy(p, NULL, 0) can therefore deference a null pointer and crash."
But again, I would say that the bug in this code is because the if condition was copy-pasted and it should be inverted.
Thanks, Denis