Accessing or modifying shared objects in signal handlers can result in race conditions that can leave data in an inconsistent state. The two exceptions (C Standard, 5.1.2.3, paragraph 5) to this rule are the ability to read from and write to lock-free atomic objects and variables of type volatile sig_atomic_t. Accessing any other type of object from a signal handler is undefined behavior. (see See undefined behavior 131.).
The need for the volatile keyword is described in DCL22-C. Use volatile for data that cannot be cached.
...
The signal handler may also call a handful of functions, including abort(). (see See SIG30-C. Call only asynchronous-safe functions within signal handlers for more information.).
Noncompliant Code Example
...
Signal handlers can refer to objects with static or thread storage duration durations that are lock-free atomic objects, as in this compliant solution:
...
SIG31-C-EX1: The C Standard, 7.14.1.1 paragraph 5 [ISO/IEC 9899:2011], makes a special exception for errno when a valid call to the signal() function results in a SIG_ERR return, allowing errno to take an indeterminate value. (see See ERR32-C. Do not rely on indeterminate values of errno.).
Risk Assessment
Accessing or modifying shared objects in signal handlers can result in accessing data in an inconsistent state. Michal Zalewski's paper "Delivering Signals for Fun and Profit" [Zalewski 2001] provides some examples of vulnerabilities that can result from violating this and other signal-handling rules.
...