Page History

No direct issues come from using the same handler for multiple signals, but it broadens your susceptibility to other vulnerabilities. For instance, be careful that a program doesn't generate two similar signals linked to the same handler, and the code to deal with it get executed twice asynchronouslyIf a signal handler is constructed with the expectation that it will only be executed once, but the handler is registered to handle multiple signals, then it may perform an operation multiple times that should only be performed once. Depending on the handler, this may provide a means to exploit other vulnerabilities. To eliminate this attack vector, each signal handler should only be registered to handle one type of signal.

Non-Compliant Coding Example

The program is intended to clean up and terminate when it receives either a SIGINT or a SIGTERM. However, if a SIGINT is generated, and then a SIGTERM is generated after the call to free(), but before _Exit() is reached, a double free() will occur. Note that this example also violates SIG30-C.

#include <signal.h> 
 
char *global_ptr; 
 
void handler() { 
  free(global_ptr); 
  _Exit(-1);
} 
 
int main() { 
  global_ptr = malloc(16);
  if (global_ptr == NULL) {
    /* handle error condition */
  }

  signal(SIGINT, handler); 
  signal(SIGTERM, handler);
 
  /* program code */

  return 0;
}

...

\[[ISO/IEC 03|AA. C References#ISO/IEC 03]\] "Signals and Interrupts"
\[[Open Group 04|AA. C References#Open Group 04]\] [longjmp|http://www.opengroup.org/onlinepubs/000095399/functions/longjmp.html]
\[OpenBSD\] [{{signal()}} Man Page|http://www.openbsd.org/cgi-bin/man.cgi?query=signal]
\[Zalewski\] [http://lcamtuf.coredump.cx/signals.txt]
\[[Dowd 06 | AA. C References#Dowd 06]\] Chapter 13, "Synchronization and State" (Signal Interruption and Repetition)