Page History

Accessing or modifying shared objects in signal handlers can result in race conditions that can leave data in an inconsistent state. The exception to this rule is the ability to read and write to lock-free atomic objects two exceptions (C Standard, subclause 55.1.2.3, paragraph 5) or to this rule are the ability to read from or and write to lock-free atomic objects and variables of type volatile sig_atomic_t. Accessing any other type of object from a signal handler is undefined behavior. (See undefined behavior 131.)

The need for the volatile keyword is described in DCL22-C. Use volatile for data that cannot be cached.

The type It is important to note that the behavior of a program that accesses an object of any other type from a signal handler is undefined. (See undefined behavior 131 in Appendix J of the C Standard.) The type sig_atomic_t is the integer type of an object that can be accessed as an atomic entity even in the presence of asynchronous interrupts. The type of sig_atomic_t is implementation-defined, though it provides some guarantees. Integer values ranging from SIG_ATOMIC_MIN through SIG_ATOMIC_MAX, inclusive, may be safely stored to a variable of the type. In addition, when sig_atomic_t is a signed integer type, SIG_ATOMIC_MIN must be no greater than −127 and SIG_ATOMIC_MAX no less than 127. Otherwise, SIG_ATOMIC_MIN must be 0 and SIG_ATOMIC_MAX must be no less than 255. The macros SIG_ATOMIC_MIN and SIG_ATOMIC_MAX are defined in the header <stdint.h>.

...

However, this issue was discussed at the April 2008 meeting of ISO/IEC WG14, and it was agreed that there are no known implementations in which it would be an error to read a value from a volatile staticsig_atomic_t variable, and the original intent of the committee was that both reading and writing variables of volatile sig_atomic_t would be strictly conforming.

The signal handler may also call a handful of functions, including abort(). (See SIG30-C. Call only asynchronous-safe functions within signal handlers for details of functions that can be safely called from within signal handlersmore information.)

Noncompliant Code Example

...

#include <signal.h>
#include <stdlib.h>
#include <string.h>

enum { MAX_MSG_SIZE = 24 };
char *err_msg;

void handler(int signum) {
  strcpy(err_msg, "SIGINT encountered.");
}

int main(void) {
  enum { MAX_MSG_SIZE = 24 };
  signal(SIGINT, handler);

  err_msg = (char *)malloc(MAX_MSG_SIZE);
  if (err_msg == NULL) {
    /* Handle error condition. */
  }
  strcpy(err_msg, "No errors yet.");

  /* Main code loop */

  return 0;
}

Compliant Solution (Writing volatile sig_atomic_t)

PortablyFor maximum portability, signal handlers can should only unconditionally set a variable of type volatile sig_atomic_t and return, as in this compliant solution:

#include <signal.h>
#include <stdlib.h>
#include <string.h>

enum { MAX_MSG_SIZE = 24 };
volatile sig_atomic_t e_flag = 0;

void handler(int signum) {
  e_flag = 1;
}

int main(void) {
  enum { MAX_MSG_SIZE = 24 }; 
  char *err_msg = (char *)malloc(MAX_MSG_SIZE);
  if (err_msg == NULL) {
    /* Handle error condition */
  }

  signal(SIGINT, handler);
  strcpy strcpy(err_msg, "No errors yet.");

  /* Main code loop */

  if (e_flag) {
    strcpy(err_msg, "SIGINT received.");
  } 
  return return 0;
}

Compliant Solution (Lock-

...

Free Atomic Access)

Signal handlers can refer to objects with static or thread storage duration durations that are lock-free atomic objects., as in this compliant solution:

#include <signal.h>
#include <stdlib.h>
#include <string.h>
#include <stdatomic.h>
 
#ifdef __STDC_NO_ATOMICS__
#error "Atomics are not supported"
#elif ATOMIC_INT_LOCK_FREE == 0
#error "int is never lock-free"
#endif

atomic_int e_flag = ATOMIC_VAR_INIT(0);
 
void handler(int signum) {
  int old_flag = atomic_load(&e_flag);
  if (old_flag != 0) {
    int new_flag;
    do {
      new_flag = 1;
    } while (!atomic_compare_exchange_weak(&e_flag, &old_flag, new_flag));
  }
}

int main(void) {
  enum { MAX_MSG_SIZE = 24 }; 
  char *err_msg = (char *)malloc([MAX_MSG_SIZE)];
#if ATOMIC_INT_LOCK_FREE == 1
  if (err_msg == NULL!atomic_is_lock_free(&e_flag)) {
    /* Handle error condition */return EXIT_FAILURE;
  }
#endif
  if (signal(SIGINT, handler) == SIG_ERR) {
    return EXIT_FAILURE;
  }
  strcpy(err_msg, "No errors yet.");

  /* Main code loop */

  if (e_flag) {
    strcpy(err_msg, "SIGINT received.");
  }
  return 0EXIT_SUCCESS;
}

Exceptions

SIG31-C-EX1:  The C Standard in subclause , 7.14.1.1 paragraph 5 5 [ISO/IEC 9899:2024], makes a special exception for errno when a valid call to the signal() function results in a SIG_ERR return, allowing errno to take an indeterminate value. (See ERR32-C. Do not rely on indeterminate values of errno.)

the signal function with the first argument equal to the signal number corresponding to the signal that caused the invocation of the handler. Furthermore, if such a call to the signal function results in a SIG_ERR return, the object designated by errno has an indeterminate representation.

Risk Assessment

Accessing or modifying shared objects in signal handlers can result in accessing data in an inconsistent state. Michal Zalewski's paper "Delivering Signals for Fun and Profit" [Zalewski 2001] provides some examples of vulnerabilities that can result from violating this and other signal-handling rules.

Automated Detection

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)

CERT-CWE Mapping Notes

Key here for mapping notes

CWE-662 and SIG31-C

CWE-662

...

= Union( SIG31-C, list) where list =

• Improper synchronization of shared objects between threads

• Improper synchronization of files between programs (enabling TOCTOU race conditions

CWE-828 and SIG31-C

CWE-828 = SIG31-C + non-async-safe things besides shared objects.

Bibliography

Bibliography

...

...

Image Modified Image Modified Image Modified