CWE-828: Signal Handler with Functionality that is not Asynchronous-Safe

Description:
The product defines a signal handler that contains code sequences that are not asynchronous-safe, i.e., the functionality is not reentrant, or it can be interrupted.

Extended Description:
This can lead to an unexpected system state with a variety of potential consequences depending on context, including denial of service and code execution. 
             Signal handlers are typically intended to interrupt normal functionality of a program, or even other signals, in order to notify the process of an event. When a signal handler uses global or static variables, or invokes functions that ultimately depend on such state or its associated metadata, then it could corrupt system state that is being used by normal functionality. This could subject the program to race conditions or other weaknesses that allow an attacker to cause the program state to be corrupted. While denial of service is frequently the consequence, in some cases this weakness could be leveraged for code execution. 
             There are several different scenarios that introduce this issue: 
                
                   Invocation of non-reentrant functions from within the handler. One example is mall

Affected languages: Not Language-Specific, C
Parent weaknesses: CWE-364

Consequences:
  - Integrity: DoS: Crash, Exit, or Restart

Detection methods:
  - Automated Static Analysis: Automated static analysis, commonly referred to as Static Application Security Testing (SAST), can find some instances of this weakness by analyzing source code (or binary/compiled code) without havin

Mitigations:
  - [Implementation] Eliminate the usage of non-reentrant functionality inside of signal handlers. This includes replacing all non-reentrant library calls with reentrant calls. 
                   Note: This will not always be possible and may require large portions of the product to be rewritten or even redesigned. Som
  - [Implementation] Where non-reentrant functionality must be leveraged within a signal handler, be sure to block or mask signals appropriately. This includes blocking other signals within the signal handler itself that may also leverage the functionality. It also includes blocking all signals reliant upon the function

Demonstrative examples:
This code registers the same signal handler function with two different signals (CWE-831). If those signals are sent to the process, the handler creates a log message (specified in the first argument to the program) and exits.
The handler function uses global state (globalVar and logMessage), and it can be called by both the SIGHUP and SIGTERM signals. An attack scenario might follow these lines:
char *logMessage; 
                      void handler (int sigNum) { 
                         syslog(LOG_NOTICE, "%s\n", logMessage); free(logMessage); 
                            /* artificially increase the size of the timing window to make demonstration of this weakness easier. */ 
                            
                            sleep(10); exit(0); 
                      } 
         

The following code registers a signal handler with multiple signals in order to log when a specific event occurs and to free associated memory before exiting.
However, the following sequence of events may result in a double-free (CWE-415):
#include <signal.h> #include <syslog.h> #include <string.h> #include <stdlib.h> 
                      void *global1, *global2; char *what; void sh (int dummy) { 
                         syslog(LOG_NOTICE,"%s\n",what); free(global2); free(global1); 
                            /* Sleep statements added to expand timing window for race condition */ 
                            
                            sleep(10); exit(0); 
                      } 
                      int main (int argc,char* argv[]) { 
                         what=argv[1]; global1=

Real-world examples:
  - CVE-2008-4109: Signal handler uses functions that ultimately call the unsafe syslog/malloc/s*printf, leading to denial of service via multiple login attempts
  - CVE-2006-5051: Chain: Signal handler contains too much functionality (CWE-828), introducing a race condition (CWE-362) that leads to a double free (CWE-415).
  - CVE-2001-1349: unsafe calls to library functions from signal handler
  - CVE-2004-0794: SIGURG can be used to remotely interrupt signal handler; other variants exist.
  - CVE-2004-2259: SIGCHLD signal to FTP server can cause crash under heavy load while executing non-reentrant functions like malloc/free.