Page History

Call only asynchronous-safe functions within signal handlers. This restriction applies to library functions as well as application-defined functions.

Wiki MarkupAccording to Section 7.14.1.1 of the C Rationale \[ [ISO/IEC 2003|AA. Bibliography#ISO/IEC 03]\]

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.

Wiki MarkupSimilarly, Section 7.14.1, paragraph 5 of C99 \ [[ISO/IEC 9899:1999|AA. Bibliography#ISO/IEC 9899-1999] \] states that if the signal occurs other than as the result of calling the {{abort}} or {{raise}} function, the behavior is [undefined|BB. Definitions#undefined behavior] if

the signal handler calls any function in the standard library 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.

...

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.

Wiki MarkupThe second problem is that the {{free()}} function is also not \ [[asynchronous-safe|AA. Bibliography#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 if SIGINT occurs after the call to free(), resulting in the memory referenced by info being freed twice. This is a violation of rules MEM31-C. Free dynamically allocated memory exactly once and SIG31-C. Do not access or modify shared objects in signal handlers.

...

Implementation Details

POSIX

...

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

Asynchronous—signal-safe functions

...

Tool	Version	Checker	Description
Section Compass/ROSE			Section can detect violations of the rule for single-file programs

Related Vulnerabilities

...

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|AA. Bibliography#Zalewski 01]\]. [VU #834865|http://www.kb.cert.org/vuls/id/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.

...

MITRE CWE: CWE ID 479, "Unsafe Function Call from a Signal Handler"

Bibliography

...

\[[Dowd 2006|AA. Bibliography#Dowd 06] \] Chapter 13, "Synchronization and State" \
[[ISO/IEC 2003|AA. Bibliography#ISO/IEC 03]\] Section 5.2.3, "Signals and interrupts" \[
[Open Group 2004|AA. Bibliography#Open Group 04]\] [longjmp|http://www.opengroup.org/onlinepubs/000095399/functions/longjmp.html] \[[OpenBSD|AA. Bibliography#OpenBSD]\] [{{signal()}} Man Page|http://www.openbsd.org/cgi-bin/man.cgi?query=signal] \[[Zalewski 2001|AA. Bibliography#Zalewski 01]\ longjmp
[OpenBSD] signal() Man Page
[Zalewski 2001]

...

      11. Signals (SIG)      SIG31-C. Do not access or modify shared objects in signal handlers