panic: oof, we didn't get our fd while playing with devfs(8) and jails

[Jilles Tjoelker]

On Mon, Jun 08, 2009 at 09:12:54PM +0200, Jille Timmermans wrote:
> I was playing with the new hierarchical jails (yay!) and devfs(8) to
> tune the devfs mountpoints. At some point I tried to apply another
> ruleset and the machine panic'd a few seconds later.
> I haven't been able to reproduce this.

> [panic: oof, we didn't get our fd from fdcheckstd() in kern_exec.c]

This KASSERT may happen if you execute a setuid/setgid program with one
or more of fd 0, 1, 2 closed, and you cannot open /dev/null (e.g. not
present, bad permissions). The assertion checks td->td_retval[0] even if
kern_open() failed. After that, if td->td_retval[0] happened to be equal
to the expected value or INVARIANTS was disabled, the function checks if
kern_open() failed. If so, it returns an error which eventually causes
"whoops, no process anymore" process termination in do_execve() (appears
as SIGABRT).

Moving the assertion below the error check seems to fix the problem (see
attached patch).

It may also be helpful to KASSERT or comment that
thread_single(SINGLE_BOUNDARY) or similar must be in effect, otherwise
our work could be undone by other threads (similar to the
KASSERT(fdp->fd_refcnt == 1) already present). kern_exec.c takes care of
both of these.

-- 
Jilles Tjoelker
-------------- next part --------------
A non-text attachment was scrubbed...
Name: fdcheckstd-fix.patch
Type: text/x-diff
Size: 577 bytes
Desc: not available
Url : http://lists.freebsd.org/pipermail/freebsd-current/attachments/20090609/675cb760/fdcheckstd-fix.bin