Goal Reached Thanks to every supporter — we hit 100%!

Goal: 1000 CNY · Raised: 1000 CNY

100.0%

CWE-364 (信号处理例程中的竞争条件) — Vulnerability Class 7

7 vulnerabilities classified as CWE-364 (信号处理例程中的竞争条件). AI Chinese analysis included.

CWE-364 represents a signal handler race condition, a concurrency weakness arising when asynchronous signal handlers interact unsafely with shared resources or global state. Because signals can interrupt normal program execution at unpredictable moments, handlers often access data structures without proper synchronization, creating a window for race conditions. Attackers typically exploit this vulnerability by triggering specific signals to manipulate the timing of execution, thereby corrupting application state or memory. This corruption can lead to severe consequences, including denial of service, arbitrary code execution, or privilege escalation. To mitigate this risk, developers must ensure that signal handlers remain simple and avoid calling non-async-signal-safe functions. Implementing robust synchronization mechanisms, such as mutexes or atomic operations, and carefully designing critical sections to exclude signal interruptions are essential strategies for preventing these dangerous race conditions in concurrent software environments.

MITRE CWE Description
The product uses a signal handler that introduces a race condition. Race conditions frequently occur in signal handlers, since signal handlers support asynchronous actions. These race conditions have a variety of root causes and symptoms. Attackers may be able to exploit a signal handler race condition to cause the product state to be corrupted, possibly leading to a denial of service or even code execution. These issues occur when non-reentrant functions, or state-sensitive actions occur in the signal handler, where they may be called at any time. These behaviors can violate assumptions being made by the "regular" code that is interrupted, or by other signal handlers that may also be invoked. If these functions are called at an inopportune moment - such as while a non-reentrant function is already running - memory corruption could occur that may be exploitable for code execution. Another signal race condition commonly found occurs when free is called within a signal handler, resulting in a double free and therefore a write-what-where condition. Even if a given pointer is set to NULL after it has been freed, a race condition still exists between the time the memory was freed and the pointer was set to NULL. This is especially problematic if the same signal handler has been set for more than one signal -- since it means that the signal handler itself may be reentered. There are several known behaviors related to signal handlers that have received the label of "signal handler …
Common Consequences (2)
Integrity, Confidentiality, AvailabilityModify Application Data, Modify Memory, DoS: Crash, Exit, or Restart, Execute Unauthorized Code or Commands
It may be possible to cause data corruption and possibly execute arbitrary code by modifying global variables or data structures at unexpected times, violating the assumptions of code that uses this global data.
Access ControlGain Privileges or Assume Identity
If a signal handler interrupts code that is executing with privileges, it may be possible that the signal handler will also be executed with elevated privileges, possibly making subsequent exploits more severe.
Mitigations (3)
RequirementsUse a language that does not allow this weakness to occur or provides constructs that make this weakness easier to avoid.
Architecture and DesignDesign signal handlers to only set flags, rather than perform complex functionality. These flags can then be checked and acted upon within the main program loop.
ImplementationOnly use reentrant functions within signal handlers. Also, use validation to ensure that state is consistent while performing asynchronous actions that affect the state of execution.
Examples (2)
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.
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); } int main (int argc, char* argv[]) { logMessage = strdup(argv[1]); /* Register signal handlers. */ signal(SIGHUP, handler); signal(SIGTERM, handler); /* artificially increase the size of the timing window to make demonstration of this weakness easier. */ sleep(10); }
Bad · C
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.
#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=strdup(argv[2]); global2=malloc(340); signal(SIGHUP,sh); signal(SIGTERM,sh); /* Sleep statements added to expand timing window for race condition */ sleep(10); exit(0); }
Bad · C

Vulnerabilities classified as CWE-364 (信号处理例程中的竞争条件) represent 7 CVEs. The CWE taxonomy describes the weakness; review individual CVEs for product-specific impact.