Call only asynchronous-safe functions within signal handlers. This restriction applies to library functions as well as application-defined functions.
According to Section 220.127.116.11 of the C Rationale [ISO/IEC 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.
Similarly, Section 18.104.22.168, para. 5, of the C standard [ISO/IEC 9899:2011], states that if the signal occurs other than as the result of calling the
raise function, the behavior is undefined if
the signal handler calls any function in the standard library other than the
_Exitfunction, or the
signalfunction 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. 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 code example, the program allocates a string on the heap and uses it to log messages in a loop. The program also registers the signal handler
int_handler() to handle the terminal interrupt signal
int_handler() function logs the last message, calls
free(), and exits.
This program's signal handler has four problems. The first is that it is unsafe to call the
fprintf() function from within a signal handler because the handler may be called when global data (such as
stderr) is in an inconsistent state. In general, it is not safe to invoke I/O functions within a signal handler.
The second problem is that the
free() function is also not asynchronous-safe, and its invocation from within a signal handler is also a violation of this rule. If an interrupt signal is received during the
free() call in
handler(), the heap may be corrupted.
The third problem is that if
SIGINT occurs after the call to
free(), the memory referenced by
info is freed twice. This is a violation of MEM31-C. Free dynamically allocated memory exactly once and SIG31-C. Do not access shared objects in signal handlers.
The fourth problem is that the signal handler reads the variable
info, which is not declared to be of type
volatile sig_atomic_t. This is a violation of SIG31-C. Do not access shared objects in signal handlers.
Furthermore, there are problems in the
main() function as well, such as the possibility that the signal handler might get invoked during the call to
The following table from the 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.
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 IEEE standard 1003.1-2001 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 is specifically covered by SIG33-C. Do not recursively invoke the raise() function.
signal() man page identifies functions that are asynchronous-signal safe. Applications may consequently invoke them, without restriction, from a signal handler.
signal() manual page lists a few additional functions that are asynchronous-safe in OpenBSD but "probably not on other systems," including
syslog_r() (but only when the
syslog_data struct is initialized as a local variable).
Signal handlers should be as concise as possible, ideally, unconditionally setting a flag and returning. They may also call the
_Exit() function. Finally, they may call other functions provided that all implementations to which the code is ported guarantee that these functions are asynchronous-safe.
This example code achieves compliance with this rule by moving the final log message and call to
free() outside the signal handler.
Invoking functions that are not asynchronous-safe from within a signal handler may result in privilege escalation and other attacks.
Can detect violations of the rule for single-file programs.
For an overview of software vulnerabilities resulting from improper signal handling, see Zalewski's paper on understanding, exploiting, and preventing signal-handling-related vulnerabilities [Zalewski 2001]. VU #834865 describes a vulnerability resulting from a violation of this rule.
Search for vulnerabilities resulting from the violation of this rule on the CERT website.
ISO/IEC 9899:2011 Section 7.14, "Signal handling
ISO/IEC TR 17961 (Draft) Calling functions in the C Standard Library other than abort, _Exit, and signal from within a signal handler [asyncsig]