SIG34-C. A signal handler should not re-assert itself

A signal handler should not re-assert its desire to handle its own signal. This is often done on non-persistent platforms, that is, when they receive a signal that is bound to a handler, they unbind the signal to default behavior before calling the handler.

A signal handler may call signal() to reset the signal, or change the current way signals are handled.

Non-Compliant Code Example

void handler(int signum) {
  signal(signum, handler);
  /* handling code */
}
/* ... */
signal(signum, handler);

Inside the handler, the signal() function permits a race window. starting when the OS first resets the signal, and ending when the handler calls signal(). During that time, a second signal sent to the program will still trigger the default signal behavior, thereby destroying the persistence implied by the signal() funtion inside the handler.

If the OS is persistent (that is, it does not reset the handler when the signal is received), the handler's signal() function is redundant.

Compliant Solution

For persistent platforms, the handler's signal() function is unnecessary.

void handler(int signum) {
  /* handling code */
}
/* ... */
signal(signum, handler);

Compliant Solution (POSIX)

POSIX defines the sigaction(2) function, which assigns handlers to signals like signal(2), but also allows one to explicitly set persistence. One can thus use sigaction(2) and sidestep the race window on non-persistent OS's.

void handler(int signum) {
  /* handling code */
}
/* ... */
/* Equivalent to signal( signum, handler);
   but make signal persistent */
struct sigaction act;
act.sa_handler = &handler;
act.sa_flags = 0;
if (sigemptyset( &act.sa_mask) != 0) {
  /* handle error */
}
if (sigaction(signum, &act, NULL) != 0) {
  /* handle error */
}

In fact, POSIX recommends sigaction(2) and deprecates signal(2). Unfortunately, sigaction(2) is not C99-compliant, and is not supported on some platforms, including Windows.

Risk Assessment

Two signals in quick succession can trigger the race condition on non-persistent platforms, thereby causing the signal's default behavior despite a handler's attempt to override it.

Related Vulnerabilities

Search for vulnerabilities resulting from the violation of this rule on the CERT website.

References

[[ISO/IEC 9899-1999TR2]] Section 7.14.1.1, "The signal function"

SIG33-C. Do not recursively invoke the raise() function      12. Signals (SIG)       13. Error Handling with errno (ERR)