bind(2): Missing [[gnu::nonnull]]

[Alejandro Colomar]

Hi Xi,

On 12/4/22 06:59, Xi Ruoyao wrote:
> On Sat, 2022-12-03 at 20:05 +0100, Andreas Schwab wrote:
>>> Currently the man page says:
>>>
>>> EFAULT: addr points outside the user's accessible address space.
>>>
>>> And bind(2) indeed sets errno to EFAULT and return -1 when NULL is
>>> passed as addr.
>>
>> You can never depend on EFAULT for invalid addresses.
> 
> Hmm, is this documented somewhere?

I don't know, but let me have an educated guess:

Holding a pointer to invalid memory is Undefined Behavior by the standard, 
except if that pointer is NULL, or is still indeterminate because the pointer 
has not yet been initialized with a valid address.  Using an uninitialized 
pointer is UB as using any uninitialized variable.  Using a NULL pointer is only 
okay for comparisons, or as a sentinel value, but never for accessing memory. 
So chances are high that the program will already have invoked UB at the time 
bind(2) is called with an invalid address.

I wonder what's the rationale for the kernel reporting EFAULT; I don't seem to 
make any sense of it.  If a program tries to access memory with an invalid 
pointer, the kernel will crash it with SEGV, but if the same program tries that 
the kernel accesses the same memory with the same invalid pointer, it will 
receive an error code and continue running fine; that's not coherent or 
consistent.  If I were the kernel I'd just do in bind(2) (and in many other 
syscalls that are similar):

if (invalid_pointer(addr))
     crash_program();

That would probably help find many hidden cases of UB around the world.

Cheers,

Alex


-- 
<http://www.alejandro-colomar.es/>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: OpenPGP_signature
Type: application/pgp-signature
Size: 833 bytes
Desc: OpenPGP digital signature
URL: <https://sourceware.org/pipermail/libc-alpha/attachments/20221204/d9cb763b/attachment-0001.sig>