...
According to Section 7.14.1.1 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 7.14.1.1, paragraph 5 of C11 para. 5, of the C standard [ISO/IEC 9899:2011], states that if the signal occurs other than as the result of calling the abort or raise function, the behavior is undefined if
...
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 if that if SIGINT occurs after the call to free(), resulting in the memory referenced by info being is freed twice. This is a violation of MEM31-C. Free dynamically allocated memory exactly once and SIG31-C. Do not access or modify 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 malloc() in main().
...
The following table from the the Open Group Base Specifications [Open Group 2004] , defines a set of functions that are asynchronous—signalasynchronous-signal-safe. Applications may invoke these functions, without restriction, from a signal handler.Asynchronous—signal-safe functions
Asynchronous-Signal-Safe Functions
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
All functions not in 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 while 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.
...
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]. VU #834865 describes a vulnerability resulting from a violation of this rule.
...
CERT C++ Secure Coding Standard: SIG30-CPP. Call only asynchronous-safe functions within signal handlers
ISO/IEC 9899:2011 Section Section 7.14, "Signal handling <signal.h>"
...
MITRE CWE: CWE ID 479, "Unsafe Function Call function call from a Signal Handlersignal handler"
Bibliography
[Dowd 2006] Chapter 13, "Synchronization and State"
[ISO/IEC 2003] Section 5.2.3, "Signals and interrupts"
[Open Group 2004] longjmp
[OpenBSD] signal() Man Page
[Zalewski 2001]
...