Page History

...

According to Section 7.14.1.1 of the C Rationale \[[ISO/IEC 032003|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.

Similarly, 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 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.

The fourth and final 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 rule SIG31-C. Do not access or modify shared objects in signal handlers.

...

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

...

Note that while raise() is on the list of asynchronous-safe functions, it is specifically covered by rule SIG33-C. Do not recursively invoke the raise() function.

...

The OpenBSD signal() man 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).

...

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—safeasynchronous-safe.

This example code achieves compliance with this rule by moving the final log message and call to free() outside the signal handler.

...

Automated Detection

...

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 012001|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.

Other Languages

Related Guidelines

CERT This rule appears in the C++ Secure Coding Standard as : SIG30-CPP. Call only asynchronous-safe functions within signal handlers

ISO/IEC 9899:1999 Section 7.14, "Signal handling <signal.h>"

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

Bibliography

\[[Dowd 062006|AA. Bibliography#Dowd 06]\] Chapter 13, "Synchronization and State"
\[[ISO/IEC 032003|AA. Bibliography#ISO/IEC 03]\] Section 5.2.3, "Signals and interrupts"
\[[ISO/IEC 9899:1999|AA. Bibliography#ISO/IEC 9899-1999]\] Section 7.14, "Signal handling {{<signal.h>}}"
\[[MITRE 07|AA. Bibliography#MITRE 07]\] [CWE ID 479|http://cwe.mitre.org/data/definitions/479.html], "Unsafe Function Call from a Signal Handler"
\[[Open Group 042004|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 012001|AA. Bibliography#Zalewski 01]\]

...