lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  PHC 
Open Source and information security mailing list archives
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:	Mon, 27 Oct 2014 10:42:36 -0400
From:	Sasha Levin <>
To:	David Miller <>
Subject: Re: [PATCH] netlink: don't copy over empty attribute data

On 10/26/2014 10:03 PM, David Miller wrote:
> From: Sasha Levin <>
> Date: Sun, 26 Oct 2014 19:32:42 -0400
>> How so? GCC states clearly that you should *never* pass a NULL
>> pointer there:
>> "The pointers passed to memmove (and similar functions in <string.h>) must
>> be non-null even when nbytes==0" (
>> Even if it doesn't dereference it, it can break somehow in a subtle way. Leaving
>> the kernel code assuming that gcc (or any other compiler) would always behave
>> the same in a situation that shouldn't occur.
> Show me a legal way in which one could legally dereference the pointer
> when length is zero, and I'll entertain this patch.

The moment you've triggered an undefined behaviour you have GCC license to
dereference anything it wants. GCC would be well within it's rights
dereferencing a NULL "from".

They even state it clearly in that GCC 4.9 porting guide I've linked above:

Calling copy(p, NULL, 0) can therefore deference a null pointer and crash.

The example above needs to be fixed to avoid the invalid memmove call, for example:

    if (nbytes != 0)
      memmove (dest, src, nbytes);

To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to
More majordomo info at

Powered by blists - more mailing lists