The software 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.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: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 software 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.