Re: Looks like split of execve(2) syscall created bugs

: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

    It's unclear whether passing a NULL argv[0] for any case is legal.
    I think to be strictly conforming, argv[0] must always be non-NULL.

    You'll have to be more specific about case (2).  What in the codebase
    are you refering to, file and line ?

					-Matt
					Matthew Dillon 
					<[e-mail]>