DragonFly bugs List (threaded) for 2005-01
Re: Looks like split of execve(2) syscall created bugs
: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 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 being NULL, the new image should see argc == 0 and
:argv = NULL. DF in this case will copy the new image path as argv
:and new image will see see it as argv/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 and argv are
:NULL, while only former is required to be to stop processing.
:The proper fix is to move special handling of argv == NULL case into
:imgact_shell.c where it belongs.
It's unclear whether passing a NULL argv for any case is legal.
I think to be strictly conforming, argv 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 ?