889
Description
The product contains a code sequence that can run concurrently with other code, and the code
sequence requires temporary, exclusive access to a shared resource, but a timing window
exists in which the shared resource can be modified by another code sequence that is operating
concurrently.
Extended Description
This can have security implications when the expected synchronization is in security-critical code,
such as recording whether a user is authenticated or modifying important state information that
should not be influenced by an outsider.
A race condition occurs within concurrent environments, and is effectively a property of a code
sequence. Depending on the context, a code sequence may be in the form of a function call, a
small number of instructions, a series of program invocations, etc.
A race condition violates these properties, which are closely related:
• Exclusivity - the code sequence is given exclusive access to the shared resource, i.e.,
no other code sequence can modify properties of the shared resource before the original
sequence has completed execution.
• Atomicity - the code sequence is behaviorally atomic, i.e., no other thread or process can
concurrently execute the same sequence of instructions (or a subset) against the same
resource.
A race condition exists when an "interfering code sequence" can still access the shared resource,
violating exclusivity. Programmers may assume that certain code sequences execute too quickly
to be affected by an interfering code sequence; when they are not, this violates atomicity. For
example, the single "x++" statement may appear atomic at the code layer, but it is actually nonatomic
at the instruction layer, since it involves a read (the original value of x), followed by a
computation (x+1), followed by a write (save the result to x).
The interfering code sequence could be "trusted" or "untrusted." A trusted interfering code
sequence occurs within the product; it cannot be modified by the attacker, and it can only be
invoked indirectly. An untrusted interfering code sequence can be authored directly by the attacker,
and typically it is external to the vulnerable product.
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 691 Insufficient Control Flow Management 1517
ParentOf 364 Signal Handler Race Condition 899
ParentOf 366 Race Condition within a Thread 904
ParentOf 367 Time-of-check Time-of-use (TOCTOU) Race Condition 906
ParentOf 368 Context Switching Race Condition 912
ParentOf 421 Race Condition During Access to Alternate Channel 1020
ParentOf 689 Permission Race Condition During Resource Copy 1513
ParentOf 1223 Race Condition for Write-Once Attributes 2001
ParentOf 1298 Hardware Logic Contains Race Conditions 2158
CanFollow 662 Improper Synchronization 1448
CWE Version 4.14
CWE-362: Concurrent Execution using Shared Resource with Improper Synchronization ('Race
Condition')
CWE-362: Concurrent Execution using Shared Resource
with Improper Synchronization ('Race Condition') 890
Relevant to the view "Weaknesses for Simplified Mapping of Published
Vulnerabilities" (CWE-1003)
Nature Type ID Name Page
ParentOf 367 Time-of-check Time-of-use (TOCTOU) Race Condition 906
Applicable Platforms
Language : C (Prevalence = Sometimes)
Language : C++ (Prevalence = Sometimes)
Language : Java (Prevalence = Sometimes)
Technology : Mobile (Prevalence = Undetermined)
Technology : ICS/OT (Prevalence = Undetermined)
Likelihood Of Exploit
Medium
Common Consequences
Scope Impact Likelihood
Availability DoS: Resource Consumption (CPU)
DoS: Resource Consumption (Memory)
DoS: Resource Consumption (Other)
When a race condition makes it possible to bypass a
resource cleanup routine or trigger multiple initialization
routines, it may lead to resource exhaustion (CWE-400).
Availability DoS: Crash, Exit, or Restart
DoS: Instability
When a race condition allows multiple control flows to
access a resource simultaneously, it might lead the
product(s) into unexpected states, possibly resulting in a
crash.
Confidentiality
Integrity
Read Files or Directories
Read Application Data
When a race condition is combined with predictable
resource names and loose permissions, it may be possible
for an attacker to overwrite or access confidential data
(CWE-59).
Detection Methods
Black Box
Black box methods may be able to identify evidence of race conditions via methods such as
multiple simultaneous connections, which may cause the software to become instable or crash.
However, race conditions with very narrow timing windows would not be detectable.
White Box
Common idioms are detectable in white box analysis, such as time-of-check-time-of-use
(TOCTOU) file operations (CWE-367), or double-checked locking (CWE-609).
Automated Dynamic Analysis
This weakness can be detected using dynamic tools and techniques that interact with the
software using large test suites with many diverse inputs, such as fuzz testing (fuzzing),
robustness testing, and fault injection. The software's operation may slow down, but it should not
become unstable, crash, or generate incorrect results. Race conditions may be detected with a
stress-test by calling the software simultaneously from a large number of threads or processes,
CWE Version 4.14
CWE-362: Concurrent Execution using Shared Resource with Improper Synchronization ('Race
Condition')
CWE-362: Concurrent Execution using Shared Resource
with Improper Synchronization ('Race Condition')