Page History

A signal handler should not reassert its desire to handle its own signal. This is often done on nonpersistent platforms; that platforms—that is, platforms that, upon receiving a signal, reset the disposition handler for the signal to default SIG_DFL before calling the bound signal handler. Calling signal() under these conditions presents a race condition.  See (See SIG01-C. Understand implementation-specific details regarding signal handler persistence.)

A signal handler may call signal() only if it does not need to be asynchronous-safe. (In other wordsthat is, if all relevant signals are masked so that the handler cannot be interrupted).)

Noncompliant Code Example

...

(POSIX)

On nonpersistent platforms, In this noncompliant code example contains a race window, starting when the host environment resets the signal and ending when the handler calls signal(). During that time, a second signal sent to the program will trigger the default signal behavior, consequently defeating the persistent behavior implied by the call to signal() from within the handler to reassert the binding.

If the environment is persistent (that is, it does not reset the handler when the signal is received), the signal() call from within the handler() function is bound to signumredundant.

#include <signal.h>
 
void handler(int signum) {
  if (signal(signum, handler) == SIG_ERR) {
    /* Handle error */
  }
  /* Handle signal */
}
 
/* ... */
void func(void) {
  if (signal(SIGUSR1, handler) == SIG_ERR) {
    /* Handle error */
  }
}

Compliant Solution (POSIX)

Calling the signal() function from within the signal On nonpersistent platforms, this solution contains a race window, starting when the host environment resets the signal and ending when the handler calls signal(). During that time, a second signal sent to the program will trigger the default signal behavior, consequently defeating the persistent behavior implied by the call to signal() from within the handler to reassert the binding .If the environment is persistent (that is, it does not reset the handler when the signal is received), the signal() call from within the handler() function is redundant.

Compliant Solution

For persistent platforms, calling the signal() function from within the signal handler is unnecessary.unnecessary for persistent platforms, as in this compliant solution:

#include <signal.h>
 
void handler(int signum) {
  /* Handle signal */
}
 
/* ... */
void func(void) {
  if (signal(SIGUSR1, handler) == SIG_ERR) {
    /* Handle error */
  }
}

Compliant Solution (POSIX)

POSIX defines the sigaction() function, which assigns handlers to signals like in a similar manner to signal() but also allows the caller to explicitly set persistence. Consequently, the sigaction() function can be used to eliminate the race window on nonpersistent operating systems.platforms, as in this compliant solution:

#include <signal.h>
#include <stddef.h>
 
void handler(int signum) {
  /* Handle signal */
}

/* ... */

void func(void) {
  struct sigaction act;
  act.sa_handler = handler;
  act.sa_flags = 0;
  if (sigemptyset( &act.sa_mask) != 0) {
    /* Handle error */
  }
  if (sigaction(SIGUSR1, &act, NULL) != 0) {
    /* Handle error */
  }
}

Although the handler in this example does not call signal(), it could do so safely because the signal is masked , and the handler cannot be interrupted. If the same handler is installed for more than one signal number, the signals must be masked explicitly in act.sa_mask to ensure that the handler cannot be interrupted because the system masks only the signal being delivered.

POSIX recommends that new applications should use sigaction() and deprecates rather than signal(). Unfortunately, The sigaction() function is not defined by the C -compliant Standard and is not supported on some platforms, including Windows.

Compliant Solution (Windows)

There is There is no safe way to implement persistent signal-handler behavior on Windows platforms, and it should not be attempted. If a design depends on this behavior, and the design cannot be altered, it may be necessary to claim a deviation from the this rule after completing an appropriate risk analysis.

The reason for this is that Windows is a nonpersistent platform as discussed above.  Just before calling the current handler function, Windows resets the handler for the next occurrence of the same signal to SIG_DFL. If the handler calls signal() to reinstall itself, there is still a race window. A signal might occur between the start of the handler and the call to signal(), which would invoke the default behavior instead of the desired handler.

Exceptions

SIG34-C-EX1: On a machine For implementations with persistent signal handlers, it is safe for a handler to modify the behavior for of its own signal. Behavior modification would modifications include having ignoring the signal be ignored, reset resetting to the default behavior, or and having the signal handled by a different handler. A handler assigning itself to its own signal reasserting its binding is also safe , as it is a no-op. Because multiple invocations of its signal will merely cause it to "interrupt itself," the handler is impervious to a race condition until it manages to reassign its signal.but unnecessary.

The following code example resets a signal handler to the system's default behavior.:

#include <signal.h>
 
void handler(int signum) {
#ifndef WINDOWS#if !defined(_WIN32)
  if (signal(signum, SIG_DFL) == SIG_ERR) {
    /* Handle error */
  }
#endif
  /* Handle signal */
}
 
/* ... */
void func(void) {
  if (signal(SIGUSR1, handler) == SIG_ERR) {
    /* Handle error */
  }
}

Risk Assessment

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

Automated Detection

...

Tool	Version	Checker	Description
Astrée	Include Page Astrée_V Astrée_V	signal-handler-signal-call	Partially checked
Axivion Bauhaus Suite	Include Page Axivion Bauhaus Suite_V Axivion Bauhaus Suite_V	CertC-SIG34
CodeSonar	Include Page CodeSonar_V CodeSonar_V	BADFUNC.SIGNAL	Use of signal
Compass/ROSE

  

			Can detect violations of this rule. However, false positives may occur on systems with persistent handlers
Cppcheck Premium	Include Page Cppcheck Premium_V Cppcheck Premium_V	premium-cert-sig34-c	Fully implemented
Helix QAC	Include Page Helix QAC_V Helix QAC_V	C5021 C++5022
Klocwork	Include Page Klocwork_V Klocwork_V	MISRA.

PRQA QA-C Include PagePRQA_VPRQA_VWarncall -wc signal

STDLIB.SIGNAL
LDRA tool suite	Include Page LDRA_V LDRA_V	97 D	Fully implemented
Parasoft C/C++test	Include Page Parasoft_V Parasoft_V	CERT_C-SIG34-a	Properly define signal handlers
PC-lint Plus	Include Page PC-lint Plus_V PC-lint Plus_V	2762, 2763	Fully supported
Polyspace Bug Finder	Include Page Polyspace Bug Finder_V Polyspace Bug Finder_V	CERT C: Rule SIG34-C	Checks for signal call from within signal handler (rule partially covered)
RuleChecker	Include Page RuleChecker_V RuleChecker_V	signal-handler-signal-call	Partially checked

Partially implemented

Related Vulnerabilities

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

Related Guidelines

Key here (explains table format and definitions)

...

Image Modified Image Modified Image Modified