On  7 Sep, Garrett Wollman wrote:
> I just noted the following:
> ../../../vm/uma_core.c:1332: could sleep with "process lock" locked from 
> lock order reversal
>  1st 0xc438e6a8 process lock (process lock) @ ../../../kern/kern_exec.c:368
>  2nd 0xc0413d20 filelist lock (filelist lock) @ ../../../kern/kern_descrip.c:1133
> ../../../vm/uma_core.c:1332: could sleep with "process lock" locked from 
> $ ident /sys/kern/kern_exec.c
> /sys/kern/kern_exec.c:
>      $FreeBSD: src/sys/kern/kern_exec.c,v 1.189 2002/09/05 07:30:14 davidxu Exp $
> $ ident /sys/kern/kern_descrip.c 
> /sys/kern/kern_descrip.c:
>      $FreeBSD: src/sys/kern/kern_descrip.c,v 1.158 2002/09/03 20:16:31 jhb Exp $
> This occurred when starting up Netscape.

I just saw this in a recent version of -stable while running mozilla. I
think the problem is in the following set?id handling code in execve():

                /* Close any file descriptors 0..2 that reference procfs */
                /* Make sure file descriptors 0..2 are in use.  */
                error = fdcheckstd(td);
                if (error != 0)
                        goto done1;

When I looked at this code before, I assumed that fdcheckstd() just
verified that the proper fds where in use, but on closer inspection it
appears that fdcheckstd() attempts to point any unused fds in 0..2 to
/dev/null.  This calls falloc(), which calls uma_zalloc() and grabs the
filelist lock, all of which happens while execve() holds the process
lock.  The do_dup() call in fdcheckstd() could also be a problem.

I don't think dropping the process lock is correct, and calling falloc()
and vn_open() before grabbing the process lock might also be insecure.
Other than just causing execve() to fail in this situation, the only
other fix that I can think of would be to preallocate the struct file
and pre-open /dev/null if we're execing a set?id executable, and then
jam this into the descriptor table if it turns out to be needed.  Barf!

I think netscape and mozilla must be exec'ing some set?id system binary
in the background and didn't pass the correct descriptors.

To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Reply via email to