DragonFly BSD
DragonFly bugs List (threaded) for 2005-01
[Date Prev][Date Next]  [Thread Prev][Thread Next]  [Date Index][Thread Index]

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

From: Matthew Dillon <dillon@xxxxxxxxxxxxxxxxxxxx>
Date: Sat, 29 Jan 2005 11:30:12 -0800 (PST)

: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.

    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 ?

					Matthew Dillon 

[Date Prev][Date Next]  [Thread Prev][Thread Next]  [Date Index][Thread Index]