On Tue, Oct 01, 2019 at 09:58:55PM +0300, Dan Carpenter wrote:
On Tue, Oct 01, 2019 at 06:13:21PM +0300, Denis Efremov wrote:
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."
Correct. In glibc those functions are annotated as non-NULL.
extern void *memcpy (void *__restrict __dest, const void *__restrict __src, size_t __n) __THROW __nonnull ((1, 2));
I was wrong on this. It's built into GCC so it doesn't matter how it's annotated.
We aren't going to do that in the kernel. A second difference is that in the kernel we use -fno-delete-null-pointer-checks so it doesn't delete the NULL checks.
But it's true that the kernel has -fno-delete-null-pointer-checks so I don't think this is worth patching.
regards, dan carpenter