1738
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 malloc(), which
modifies internal global variables as it manages memory. Very few functions are actually
reentrant.
• Code sequences (not necessarily function calls) contain non-atomic use of global variables, or
associated metadata or structures, that can be accessed by other functionality of the program,
including other signal handlers. Frequently, the same function is registered to handle multiple
signals.
• The signal handler function is intended to run at most one time, but instead it can be invoked
multiple times. This could happen by repeated delivery of the same signal, or by delivery of
different signals that have the same handler function (CWE-831).
Note that in some environments or contexts, it might be possible for the signal handler to be
interrupted itself.
If both a signal handler and the normal behavior of the product have to operate on the same set
of state variables, and a signal is received in the middle of the normal execution's modifications
of those variables, the variables may be in an incorrect or corrupt state during signal handler
execution, and possibly still incorrect or corrupt upon return.
Relationships
The table(s) below shows the weaknesses and high level categories that are related to this
weakness. These relationships are defined as ChildOf, ParentOf, MemberOr and give insight to
similar items that may exist at higher and lower levels of abstraction. In addition, relationships such
as PeerOf and CanAlsoBe are defined to show similar weaknesses that may want to be explored.
Relevant to the view "Research Concepts" (CWE-1000)
Nature Type ID Name Page
ChildOf 364 Signal Handler Race Condition 899
ParentOf 479 Signal Handler Use of a Non-reentrant Function 1147
Common Consequences
Scope Impact Likelihood
Integrity
Confidentiality
Availability
DoS: Crash, Exit, or Restart
Execute Unauthorized Code or Commands
The most common consequence will be a corruption
of the state of the product, possibly leading to a crash
or exit. However, if the signal handler is operating on
state variables for security relevant libraries or protection
mechanisms, the consequences can be far more severe,
including protection mechanism bypass, privilege
escalation, or information exposure.
Potential Mitigations
Phase: Implementation
Phase: Architecture and Design
CWE Version 4.14
CWE-828: Signal Handler with Functionality that is not Asynchronous-Safe
CWE-828: Signal Handler with Functionality that is not Asynchronous-Safe