Looks like split of execve(2) syscall created bugs

[Maxim Sobolev]

Another regression of execve() is that now it doesn't return error value 
if NULL has been passed as its second argument.

-Maxim

Maxim Sobolev wrote:
Hi DF'ers!

I am working on eliminating stackgap in FreeBSD's linuxlator following 
DF's footsteps and fond that there is potential bug has been introduced 
into execve(). The problem is that DF now first checks if argv[0] is 
NULL, then replaces it with pathname and then proceeds with scanning 
other arguments instead of stopping there. According to the comment in 
the code, such behaviour has been introduced to make shell scripts 
working. However there are two problems with this approach:

1. According to the POSIX, execve() should pass arguments list 
unmodified to the newly created process. This means that if I invoke 
execve with argv[0] being NULL, the new image should see argc == 0 and 
argv[0] = NULL. DF in this case will copy the new image path as argv[0] 
and new image will see see it as argv[0]/argc == 1.

2. In some cases, the new logic will result in bogus arguments passed to 
the new image or EFAULT when first argument is NULL. This will happen 
due to the bug in routine which copies arguments from the user space 
into the kernel space. It assumes that both argv[0] and argv[1] are 
NULL, while only former is required to be to stop processing.

The proper fix is to move special handling of argv[0] == NULL case into 
imgact_shell.c where it belongs.

-Maxim