]> git.hungrycats.org Git - linux/commit
[PATCH] signal handling race fix
authorCorey Minyard <minyard@acm.org>
Wed, 25 Aug 2004 11:00:58 +0000 (04:00 -0700)
committerLinus Torvalds <torvalds@ppc970.osdl.org>
Wed, 25 Aug 2004 11:00:58 +0000 (04:00 -0700)
commitffe362b00ee53b3d4c78939a3fa9eafc9fce949e
tree536ae5a57b314f31ac2459cc7591b0a120af1110
parenta6fc012c29375366c531f5e31f8ad85e806eefc1
[PATCH] signal handling race fix

The problem:

  In arch/i386/signal.c, in the do_signal() function, it calls
  get_signal_to_deliver() which returns the signal number to deliver (along
  with siginfo).  get_signal_to_deliver() grabs and releases the lock, so
  the signal handler lock is not held in do_signal().  Then the do_signal()
  calls handle_signal(), which uses the signal number to extract the
  sa_handler, etc.

  Since no lock is held, it seems like another thread with the same
  signal handler set can come in and call sigaction(), it can change
  sa_handler between the call to get_signal_to_deliver() and fetching the
  value of sa_handler.  If the sigaction() call set it to SIG_IGN, SIG_DFL,
  or some other fundamental change, that bad things can happen.

The patch:

  You have to get the sigaction information that will be delivered while
  holding sighand->siglock in get_signal_to_deliver().

  In 2.4, it can be fixed per-arch and requires no change to the
  arch-independent code because the arch fetches the signal with
  dequeue_signal() and does all the checking.

The test app:

  The program below has three threads that share signal handlers.  Thread
  1 changes the signal handler for a signal from a handler to SIG_IGN and
  back.  Thread 0 sends signals to thread 3, which just receives them.
  What I believe is happening is that thread 1 changes the signal handler
  in the process of thread 3 receiving the signal, between the time that
  thread 3 fetches the signal info using get_signal_to_deliver() and
  actually delivers the signal with handle_signal().

  Although the program is obvously an extreme case, it seems like any
  time you set the handler value of a signal to SIG_IGN or SIG_DFL, you can
  have this happen.  Changing signal attributes might also cause problems,
  although I am not so sure about that.

  (akpm: this test app segv'd on SMP within milliseconds for me)

#include <signal.h>
#include <stdio.h>
#include <sched.h>

char stack1[16384];
char stack2[16384];

void sighnd(int sig)
{
}

int child1(void *data)
{
struct sigaction act;

sigemptyset(&act.sa_mask);
act.sa_flags = 0;
for (;;) {
act.sa_handler = sighnd;
sigaction(45, &act, NULL);
act.sa_handler = SIG_IGN;
sigaction(45, &act, NULL);
}
}

int child2(void *data)
{
for (;;) {
sleep(100);
}
}

int main(int argc, char *argv[])
{
int pid1, pid2;

signal(45, SIG_IGN);
pid2 = clone(child2, stack2 + sizeof(stack2) - 8,
CLONE_SIGHAND | CLONE_VM, NULL);
pid1 = clone(child1, stack1 + sizeof(stack2) - 8,
CLONE_SIGHAND | CLONE_VM, NULL);

for (;;) {
kill(pid2, 45);
}
}

Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
arch/i386/kernel/signal.c
include/linux/signal.h
kernel/signal.c