Page History

Accessing or modifying shared objects in signal handlers can result in race conditions that can leave data in an inconsistent state. The exception to this rule is the ability to read and write to variables of volatile sig_atomic_t. The need for the volatile keyword is described in rule DCL34-C. Use volatile for data that cannot be cached. It is important to note that the behavior of a program that accesses an object of any other type from a signal handler is undefined. (see See undefined behavior 125 of Appendix J of C99.).

The type sig_atomic_t is the integer type of an object that can be accessed as an atomic entity, even in the presence of asynchronous interrupts. The type of sig_atomic_t is implementation defined, though it provides some guarantees. Integer values ranging from SIG_ATOMIC_MIN through SIG_ATOMIC_MAX, inclusive, may be safely stored to a variable of the type. In addition, when sig_atomic_t is a signed integer type, SIG_ATOMIC_MIN must be no greater than -127 and SIG_ATOMIC_MAX no less than 127. Otherwise, SIG_ATOMIC_MIN must be 0 and SIG_ATOMIC_MAX must be no less than 255. The macros SIG_ATOMIC_MIN and SIG_ATOMIC_MAX are defined in the header <stdint.h>.

According to the "Signals and Interrupts" section of the C99 Rationale \[[ISO/IEC 032003|AA. Bibliography#ISO/IEC 03]\], other than calling a limited, prescribed set of library functions,

The C89 Committee concluded that about the only thing a strictly conforming program can do in a signal handler is to assign a value to a volatile static variable which can be written uninterruptedly and promptly return.

...

The signal handler may also call a handful of functions, including abort(). (See rule SIG30-C. Call only asynchronous-safe functions within signal handlers for details of functions that can be safely called from within signal handlers.)

...

The noncompliant code example below declares volatile an object with static storage duration that is accessed in the signal handler. However, since the type of the object is not sig_atomic_t, the behavior of the program is undefined. Note that the behavior of the program is undefined also because the handler for the SIGFPE signal returns. See undefined behavior 123 of Appendix J of C99.

...

Accessing or modifying shared objects in signal handlers can result in accessing data in an inconsistent state. Zalewski's paper "Delivering Signals for Fun and Profit" provides some examples of vulnerabilities that can result from violating this and other signal-handling rules \[[Zalewski 012001|AA. Bibliography#Zalewski 01]\].

Automated Detection

...

Related Vulnerabilities

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 : SIG31-CPP. Do not access or modify shared objects in signal handlers.

MITRE CWE: CWE ID 662, "Insufficient Synchronization"

Bibliography

\[[Dowd 062006|AA. Bibliography#Dowd 06]\] Chapter 13, Synchronization and State
\[[ISO/IEC 032003|AA. Bibliography#ISO/IEC 03]\] "Signals and Interrupts"
\[[MITRE 07|AA. Bibliography#MITRE 07]\] [CWE ID 662|http://cwe.mitre.org/data/definitions/662.html], "Insufficient Synchronization"
\[[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]\]

...