Race conditions accessing sig->action?

From: Paul Menage (pmenage@ensim.com)
Date: Thu Oct 11 2001 - 18:11:24 EST

The task->sig->siglock spinlock is only used in do_sigaction(), and not
in the arch-specific signal dispatch code nor the signal copying code
in fs/exec.c and kernel/fork.c. While this is fine if the signal
structures aren't shared between processes, if they are then it seems as
though some race conditions can creep in, e.g.

- one thread changes the SIGCHLD handler from a handler to SIG_IGN just
as a different thread on a different CPU receives a SIGCHLD. The second
thread can end up segfaulting, as by the time we get to setting up the
signal frame, sa_handler for SIGCHLD has changed from a valid pointer to

- one thread fork()s just as another thread changes the signal handler
for a signal, and copy_sighand() catches the handler structure in an
inconsistent state.

These are pretty unlikely races, and it could be regarded as an error
for user-space to change a shared signal handler anyway. If that's the
case, shouldn't we return an error from sigaction() if the sig->count
structure is not 1.

If changing shared signal handlers is really required (e.g. for
pthreads?) then - unless I'm missing something fundamental -
copy_sighand() and the signal dispatch code ought to take siglock. The
dispatch code would probably need to copy the relevant parts of the
signal action within the spinlock, and use the copy, since setting up
the signal frame can block on page faults.

On a separate note, there seems to be a lot of duplication of code in
the various arch-specific signal dispatch code. Would there be
objections to a patch to bring some of this functionality (for those
architectures that are fairly similar) back into the arch-independent
signal code?


To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

This archive was generated by hypermail 2b29 : Mon Oct 15 2001 - 21:00:42 EST