Page History

Call only asynchronous-safe functions within signal handlers. For strictly conforming programs, only the C standard library functions abort(), _Exit(), quick_exit(), and signal() can be safely called from within a signal handler. 

Subclause 7The C Standard, 7.14.1.1, paragraph 5 , of the C Standard  [ISO/IEC 9899:20112024], states that if the signal occurs other than as the result of calling the abort() or raise() function, the behavior is undefined if if

If the signal handler calls any function in the standard library occurs other than the abort function, the _Exit function, or the signal function with the first argument equal to the signal number corresponding to the signal that caused the invocation of the handler. 

Many systems define an implementation-specific list of asynchronous-safe functions. These functions can also be called within a signal handler. This restriction applies to library functions as well as application-defined functions.

According to Subclause 7.14.1.1 of the C Rationale [C99 Rationale 2003],

When a signal occurs, the normal flow of control of a program is interrupted. If a signal occurs that is being trapped by a signal handler, that handler is invoked. When it is finished, execution continues at the point at which the signal occurred. This arrangement can cause problems if the signal handler invokes a library function that was being executed at the time of the signal.

In general, I/O functions are not safe to invoke inside signal handlers. Check your system's asynchronous-safe functions before using them in signal handlers.

Noncompliant Code Example

In this noncompliant example, the C standard library function fprintf() is called from the signal handler via the function log_message(). The function free() is also not asynchronous-safe, and its invocation from within a signal handler is also a violation of this rule.

as the result of calling the abort or raise function, the behavior is undefined if the signal handler refers to any object with static or thread storage duration that is not a lock-free atomic object and that is not declared with the constexpr storage-class specifier other than by assigning a value to an object declared as volatile sig_atomic_t, or the signal handler calls any function in the standard library other than

—  the abort function,

—  the _Exit function,

—  the quick_exit function,

—  the functions in <stdatomic.h> (except where explicitly stated otherwise) when the atomic arguments are lock-free,

—  the atomic_is_lock_free function with any atomic argument, or

—  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.294)

Implementations may define a list of additional asynchronous-safe functions. These functions can also be called within a signal handler. This restriction applies to library functions as well as application-defined functions.

According to the C Rationale, 7.14.1.1 [C99 Rationale 2003],

When a signal occurs, the normal flow of control of a program is interrupted. If a signal occurs that is being trapped by a signal handler, that handler is invoked. When it is finished, execution continues at the point at which the signal occurred. This arrangement can cause problems if the signal handler invokes a library function that was being executed at the time of the signal.

In general, it is not safe to invoke I/O functions from within signal handlers. Programmers should ensure a function is included in the list of an implementation's asynchronous-safe functions for all implementations the code will run on before using them in signal handlers.

Noncompliant Code Example

In this noncompliant example, the C standard library functions fputs() and free() are called from the signal handler via the function log_message(). Neither function is asynchronous-safe.

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

enum { MAXLINE = 1024 };
char *info = NULL;

void log_message

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

enum { MAXLINE = 1024 };
char *info = NULL;

void log_message(void) {
  fprintf(stderr, info);
}

void handler(int signum) {
  log_message();
  free(info);
  info = NULL;
}

int main(void) {
  if (signal(SIGINTfputs(info, handler) =stderr);
}

void handler(int signum) {
  log_message();
  free(info);
  info = NULL;
}

int main(void) {
  if (signal(SIGINT, handler) == SIG_ERR) {
    /* Handle error */
  }
  info = (char *)malloc(MAXLINE);
  if (info == NULL) {
    /* Handle Error */
  }

  while (1) {
    /* Main loop program code */

    log_message();

    /* More program code */
  }
  return 0;
}

...

Signal handlers should be as concise as possible—ideally , by unconditionally setting a flag and returning. This compliant solution sets a flag of type volatile sig_atomic_t and returns; the log_message() and free() functions are called directly from main():

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

enum { MAXLINE = 1024 };
volatile sig_atomic_t eflag = 0;
char *info = NULL;

void log_message(void) {
  fprintffputs(stderrinfo, infostderr);
}

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

int main(void) {
  if (signal(SIGINT, handler) == SIG_ERR) {
    /* Handle error */
  }
  info = (char *)malloc(MAXLINE);
  if (info == NULL) {
    /* Handle error */
  }

  while (!eflag) {
    /* Main loop program code */

    log_message();

    /* More program code */
  }

  log_message();
  free(info);
  info = NULL;

  return 0;
}

Noncompliant Code Example (longjmp())

Invoking the longjmp() function from within a signal handler can lead to undefined behavior if it results in the invocation of any non-asynchronous-safe functions, likely compromising the integrity of the program. Consequently, neither longjmp() nor the POSIX siglongjmp() should functions should ever be called from within a signal handler.

...

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

enum { MAXLINE = 1024 };
static jmp_buf env;

void handler(int signum) {
  longjmp(env, 1);
}

void log_message(char *info1, char *info2) {
  static char *buf = NULL;
  static size_t bufsize;
  char buf0[MAXLINE];

  if (buf == NULL) {
    buf = buf0;
    bufsize = sizeof(buf0);
  }

  /*
   * Try to fit a message into buf, else reallocate
   * it on the heap and then log the message.
   */

  /*** VULNERABILITY IF Program is vulnerable if SIGINT is RAISEDraised HEREhere ***/

  if (buf == buf0) {
    buf = NULL;
  }
}

int main(void) {
  if (signal(SIGINT, handler) == SIG_ERR) {
    /* Handle error */
  }
  char *info1;
  char *info2;

  /* info1 and info2 are set by user input here */

  if (setjmp(env) == 0) {
    while (1) {
      /* Main loop program code */
      log_message(info1, info2);
      /* More program code */
    }
  } else {
    log_message(info1, info2);
  }

  return 0;
}

...

In this compliant solution, the call to longjmp() is removed; the signal handler sets an error flag of type volatile sig_atomic_t insteadinstead:

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

enum { MAXLINE = 1024 };
volatile sig_atomic_t eflag = 0;

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

void log_message(char *info1, char *info2) {
  static char *buf = NULL;
  static size_t bufsize;
  char buf0[MAXLINE];

  if (buf == NULL) {
    buf = buf0;
    bufsize = sizeof(buf0);
  }

  /*
   * Try to fit a message into buf, else reallocate
   * it on the heap and then log the message.
   */
  if (buf == buf0) {
    buf = NULL;
  }
}

int main(void) {
  if (signal(SIGINT, handler) == SIG_ERR) {
    /* Handle error */
  }
  char *info1;
  char *info2;

  /* info1 and info2 are set by user input here */

  while (!eflag) {
    /* Main loop program code */
    log_message(info1, info2);
    /* More program code */
  }

  log_message(info1, info2);

  return 0;
}

Noncompliant Code Example (raise())

In this noncompliant code example, the int_handler() function is used to carry out SIGINT-specific tasks out tasks specific to SIGINT and then raises a  SIGTERM. However, there is a nested call to the raise() function, which results in is undefined behavior.

#include <signal.h>
#include <stdlib.h>
 
void term_handler(int signum) {
  /* SIGTERM handling specifichandler */
}
 
void int_handler(int signum) {
  /* SIGINT handlinghandler specific */
  if (raise(SIGTERM) != 0) {
    /* Handle error */
  }
}
 
int main(void) {
  if (signal(SIGTERM, term_handler) == SIG_ERR) {
    /* Handle error */
  }
  if (signal(SIGINT, int_handler) == SIG_ERR) {
    /* Handle error */
  }
 
  /* Program code */
  if (raise(SIGINT) != 0) {
    /* Handle error */
  }
  /* More code */
 
  return EXIT_SUCCESS;
}

...

In this compliant solution, the call to the raise() function inside  int_handler() is replaced by a direct call to log_msg(): invokes term_handler() instead of raising SIGTERM: 

#include <signal.h>
#include <stdlib.h>
 
void logterm_msghandler(int signum) {
  /* Log error message in some asynchronous-safe manner SIGTERM handler */
}
 
void int_handler(int signum) {
  /* DoSIGINT somehandler handling specific*/
  /* Pass control to SIGINTthe SIGTERM handler */
  logterm_msghandler(SIGUSR1SIGTERM);
}
 
int main(void) {
  if (signal(SIGUSR1SIGTERM, logterm_msghandler) == SIG_ERR) {
    /* Handle error */
  }
  if (signal(SIGINT, int_handler) == SIG_ERR) {
    /* Handle error */
  }
 
  /* Program code */
  if (raise(SIGINT) != 0) {
    /* Handle error */
  }
  /* More code */
 
  return 0EXIT_SUCCESS;
}

Noncompliant Code Example (POSIX)

Implementation Details

POSIX

The following table from the POSIX The POSIX standard [IEEE Std 1003.1:2013] is contradictory regarding raise() in signal handlers. It prohibits signal handlers installed using signal() from calling the raise() function if the signal occurs as the result of calling the raise(), kill(), pthread_kill(), or sigqueue() functions. However, it allows the raise() function to be safely called within any signal handler. Consequently, it is not clear whether it is safe for POSIX applications to call raise() in signal handlers installed using signal(), but it is safe to call raise() in signal handlers installed using sigaction(). 

In this noncompliant code example, the signal handlers are installed using signal(), and raise() is called inside the signal handler:

#include <signal.h>

void log_msg(int signum) {
  /* Log error message */
}

void handler(int signum) {
  /* Do some handling specific to SIGINT */
  if (raise(SIGUSR1) != 0) {
    /* Handle error */
  }
}

int main(void) {
  signal(SIGUSR1, log_msg);
  signal(SIGINT, handler);
   
  /* Program code */
  if (raise(SIGINT) != 0) {
    /* Handle error */
  }
  /* More code */

  return 0;
}

Implementation Details

POSIX

The following table from the Open Group Base Specifications [Open Group 2004] defines a set of functions that are asynchronous-signal-safe. Applications may invoke these functions, without restriction, from a signal handler.

Asynchronous-Signal-Safe Functions 

All functions not listed in this table are considered to be unsafe with respect to signals. In the presence of signals, all functions defined by Standard for Information Technology—Portable Operating System Interface (POSIX®), Base Specifications, Issue 7 (IEEE Std 1003.1, 2013 Edition) behave as defined when called from or interrupted by a signal handler, with a single exception: when a signal interrupts an unsafe function and the signal handler calls an unsafe function, the behavior is undefined.

Note that although raise() is on the list of asynchronous-safe functions, it should not be called within a signal handler if the signal occurs as a result of the abort() or raise() function.

Subclause 7.14.1.1, paragraph 4, of the C Standard [ISO/IEC 9899:2011] states:

  If the signal occurs as the result of calling the abort or raise function, the signal handler shall not call the raise function.

 (See also undefined behavior 131 in Annex J.)

OpenBSD

The OpenBSD signal() man page identifies functions that are asynchronous-signal safe. Applications may consequently invoke them, without restriction, from a signal handler. 

The OpenBSD signal() manual page lists a few additional functions that are asynchronous-safe in OpenBSD but "probably not on other systems," including snprintf(), vsnprintf(), and syslog_r() (but only when the syslog_data struct is initialized as a local variable).

Compliant Solution (POSIX)

In this compliant solution, the signal handlers are installed using sigaction(), and so it is safe to use raise() within the signal handler:

#include <signal.h>

void log_msg(int signum) {
  /* Log error message in some asynchronous-safe manner */
}

void handler(int signum) {
  /* Do some handling specific to SIGINT */
  if (raise(SIGUSR1) != 0) {
    /* Handle error */
  }
}

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

  /* Program code */
  if (raise(SIGINT) != 0) {
    /* Handle error */
  }
  /* More code */

  return 0;
}

POSIX recommends sigaction() and deprecates signal(). Unfortunately, sigaction() is not defined in the C Standard and is consequently not as portable a solution.

Risk Assessment

Invoking functions that are not asynchronous-safe from within a signal handler may result in privilege escalation and other attacks.

Automated Detection

defines a set of functions that are asynchronous-signal-safe. Applications may invoke these functions, without restriction, from a signal handler.

All functions not listed in this table are considered to be unsafe with respect to signals. In the presence of signals, all POSIX functions behave as defined when called from or interrupted by a signal handler, with a single exception: when a signal interrupts an unsafe function and the signal handler calls an unsafe function, the behavior is undefined.

The C Standard, 7.14.1.1, paragraph 4 [ISO/IEC 9899:2011], states

If the signal occurs as the result of calling the abort or raise function, the signal handler shall not call the raise function.

However, in the description of signal(), POSIX [IEEE Std 1003.1:2013] states

This restriction does not apply to POSIX applications, as POSIX.1-2008 requires raise() to be async-signal-safe.

See also undefined behavior 131. 

OpenBSD

The OpenBSD signal() manual page lists a few additional functions that are asynchronous-safe in OpenBSD but "probably not on other systems" [OpenBSD], including snprintf(), vsnprintf(), and syslog_r() but only when the syslog_data struct is initialized as a local variable.

Risk Assessment

Invoking functions that are not asynchronous-safe from within a signal handler is undefined behavior.

Automated Detection

Related Vulnerabilities

For an overview of software vulnerabilities resulting from improper signal handling, see Michal Zalewski's paper "Delivering Signals for Fun and Profit" [Zalewski 2001] on understanding, exploiting, and preventing signal-handling-related vulnerabilities. VU #834865 .

CERT Vulnerability Note VU #834865, "Sendmail signal I/O race condition," describes a vulnerability resulting from a violation of this rule. Another notable case where using the longjmp() function in a signal handler caused a serious vulnerability is wu-ftpd 2.4 [Greenman 1997]. The effective user ID is set to 0 in one signal handler. If a second signal interrupts the first, a call is made to longjmp(), returning the program to the main thread but without lowering the user's privileges. These escalated privileges can be used for further exploitation.

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

Related Guidelines

Key here (explains table format and definitions)

Bibliography

...

...

Image Modified Image Modified Image Modified

adjust column widths