Signal Handler Race Condition
Weakness ID: 364 (Weakness Base)Status: Incomplete
+ Description

Description Summary

Race conditions occur frequently in signal handlers, since they are asynchronous actions. These race conditions may have any number of root-causes and symptoms.
+ Time of Introduction
  • Architecture and Design
  • Implementation
+ Applicable Platforms


C: (Sometimes)

C++: (Sometimes)

+ Common Consequences

It may be possible to execute arbitrary code through the use of a write-what-where condition.


Signal race conditions often result in data corruption.

+ Likelihood of Exploit


+ Demonstrative Examples

Example 1

(Bad Code)
Example Language:
#include <signal.h>
#include <syslog.h>
#include <string.h>
#include <stdlib.h>

void *global1, *global2;
char *what;
void sh (int dummy) {

int main (int argc,char* argv[]) {
+ Observed Examples
+ Potential Mitigations

Requirements specification: A language might be chosen, which is not subject to this flaw, through a guarantee of reentrant code.

Phase: Architecture and Design

Design signal handlers to only set flags rather than perform complex functionality.

Phase: Implementation

Ensure that non-reentrant functions are not found in signal handlers. Also, use sanity checks to ensure that state is consistent be performing asynchronous actions which effect the state of execution.

+ Other Notes

Signal race conditions are a common issue that have only recently been seen as exploitable. These issues occur when non-reentrant functions, or state-sensitive actions occur in the signal handler, where they may be called at any time. If these functions are called at an inopportune moment -- such as while a non-reentrant function is already running --, memory corruption occurs that may be exploitable. 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. This is a perfect example of a signal handler taking actions which cannot be accounted for in state. 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 prudent if the same signal handler has been set for more than one signal -- since it means that the signal handler itself may be reentered.

+ Relationships
NatureTypeIDNameView(s) this relationship pertains toView(s)
ChildOfCategoryCategory361Time and State
Seven Pernicious Kingdoms (primary)700
ChildOfWeakness ClassWeakness Class362Race Condition
Development Concepts (primary)699
Research Concepts (primary)1000
ChildOfCategoryCategory387Signal Errors
Development Concepts699
ChildOfCategoryCategory634Weaknesses that Affect System Processes
Resource-specific Weaknesses (primary)631
CanPrecedeWeakness BaseWeakness Base123Write-what-where Condition
Research Concepts1000
PeerOfWeakness VariantWeakness Variant415Double Free
Research Concepts1000
PeerOfWeakness BaseWeakness Base416Use After Free
Research Concepts1000
PeerOfWeakness VariantWeakness Variant479Unsafe Function Call from a Signal Handler
Research Concepts1000
PeerOfWeakness BaseWeakness Base365Race Condition in Switch
Research Concepts1000
CanAlsoBeWeakness BaseWeakness Base368Context Switching Race Condition
Research Concepts1000
+ Research Gaps

Probably under-studied.

+ Affected Resources
  • System Process
+ Functional Areas
  • Signals, interprocess communication
+ Taxonomy Mappings
Mapped Taxonomy NameNode IDFitMapped Node Name
PLOVERSignal handler race condition
7 Pernicious KingdomsSignal Handling Race Conditions
CLASPRace condition in signal handler
+ Content History
Submission DateSubmitterOrganizationSource
PLOVERExternally Mined
Modification DateModifierOrganizationSource
2008-07-01Eric DalciCigitalExternal
updated Time of Introduction
2008-09-08CWE Content TeamMITREInternal
updated Applicable Platforms, Common Consequences, Relationships, Other Notes, Taxonomy Mappings