Category: Comprehensive Categorization: Concurrency
Incomplete
Summary
Weaknesses in this category are related to concurrency.
Membership
| ID | Name | Description |
|---|---|---|
| CWE-1058 | Invokable Control Element in Multi-Thread Context with non-Final Static Storable or Member Element | This happens when a method or function, designed to run in a multi-threaded environment, accesses or modifies a non-final static variable or class member. Because the static element is not final, its state can be changed unexpectedly by concurrent threads, leading to race conditions and unpredictable behavior. |
| CWE-1088 | Synchronous Access of Remote Resource without Timeout | This vulnerability occurs when an application makes a synchronous call to a remote service or resource but does not set a timeout, or sets an infinite one. This leaves the application waiting indefinitely for a response. |
| CWE-1096 | Singleton Class Instance Creation without Proper Locking or Synchronization | This flaw occurs when a Singleton class is implemented without proper thread-safe controls, allowing multiple instances to be created in concurrent environments. |
| CWE-1223 | Race Condition for Write-Once Attributes | This vulnerability occurs when an untrusted software component wins a race condition and writes to a hardware register before the trusted component can, permanently locking in an insecure value because the register is designed to be written only once. |
| CWE-1232 | Improper Lock Behavior After Power State Transition | This vulnerability occurs when a hardware lock bit, designed to protect critical system configuration registers, is improperly reset or becomes programmable after a device transitions between power states, such as entering or waking from a low-power sleep mode. This allows the protected configuration to be altered after it should be permanently locked. |
| CWE-1234 | Hardware Internal or Debug Modes Allow Override of Locks | Hardware debug modes or internal states can bypass critical system lock protections, allowing unauthorized changes to device configuration. |
| CWE-1264 | Hardware Logic with Insecure De-Synchronization between Control and Data Channels | This vulnerability occurs when a hardware design incorrectly forwards data before its security or permission checks have finished processing. It's a timing flaw where the data channel gets ahead of the control channel, potentially leaking information. |
| CWE-1298 | Hardware Logic Contains Race Conditions | A hardware race condition occurs when security-critical logic circuits receive signals at slightly different times, creating temporary glitches that can bypass system protections. |
| CWE-362 | Concurrent Execution using Shared Resource with Improper Synchronization ('Race Condition') | A race condition occurs when multiple processes or threads access a shared resource simultaneously without proper coordination, creating a timing window where the resource's state can be unexpectedly altered, leading to unpredictable behavior or security vulnerabilities. |
| CWE-363 | Race Condition Enabling Link Following | This vulnerability occurs when a program checks a file's status before using it, creating a brief window where an attacker can replace that file with a malicious link. This causes the program to follow the link and access an unintended, potentially dangerous location. |
| CWE-364 | Signal Handler Race Condition | A signal handler race condition occurs when a program's signal handling routine is vulnerable to timing issues, allowing its state to be corrupted through asynchronous execution. |
| CWE-366 | Race Condition within a Thread | This vulnerability occurs when two or more threads within the same application access and manipulate a shared resource (like a variable, data structure, or file) without proper synchronization. Because the threads can execute in an unpredictable order, they can corrupt the resource's state, leading to crashes, incorrect calculations, or data loss. |
| CWE-367 | Time-of-check Time-of-use (TOCTOU) Race Condition | This vulnerability occurs when a program verifies a resource's state (like a file's permissions or existence) but then uses it after that state has already changed. The gap between checking and using creates a race window where an attacker can manipulate the resource, causing the program to operate on invalid or malicious data. |
| CWE-368 | Context Switching Race Condition | This vulnerability occurs when an application switches between different security contexts (like privilege levels or domains) using a series of steps that can be interrupted. An attacker can exploit the timing gap during this switch to trick the application into performing actions with the wrong permissions or resources. |
| CWE-412 | Unrestricted Externally Accessible Lock | This vulnerability occurs when a system correctly checks for a lock's existence, but an unauthorized external actor can control or influence that lock. |
| CWE-413 | Improper Resource Locking | This vulnerability occurs when an application fails to properly lock a shared resource, such as a file or memory location, before performing operations that require exclusive access. |
| CWE-414 | Missing Lock Check | This vulnerability occurs when software fails to verify that a proper synchronization lock is active before accessing or modifying a shared resource, potentially leading to race conditions and data corruption. |
| CWE-432 | Dangerous Signal Handler not Disabled During Sensitive Operations | This vulnerability occurs when a program's signal handler, which shares resources like global variables with other handlers, can be interrupted and re-entered before it finishes its work. The program fails to block other signals during this sensitive operation, leaving shared state vulnerable to corruption. |
| CWE-479 | Signal Handler Use of a Non-reentrant Function | This vulnerability occurs when a signal handler in your code calls a function that is not safe to re-enter. If that function is interrupted and called again before it finishes, it can corrupt memory and crash your program or create security weaknesses. |
| CWE-543 | Use of Singleton Pattern Without Synchronization in a Multithreaded Context | This vulnerability occurs when a singleton pattern is implemented in a multithreaded application without proper synchronization, potentially leading to multiple instances or corrupted state. |
| CWE-558 | Use of getlogin() in Multithreaded Application | Using the getlogin() function in a multithreaded application can lead to unreliable or incorrect username results, creating security and logic flaws. |
| CWE-567 | Unsynchronized Access to Shared Data in a Multithreaded Context | This vulnerability occurs when multiple threads in an application can read and modify shared data, like static variables, without proper coordination. This unsynchronized access corrupts data, causes crashes, and leads to unpredictable, often security-critical, behavior. |
| CWE-572 | Call to Thread run() instead of start() | This vulnerability occurs when a program incorrectly calls a thread's `run()` method directly, instead of using the `start()` method. This mistake causes the thread's code to execute within the caller's current thread, bypassing the creation of a new, concurrent thread of execution. |
| CWE-574 | EJB Bad Practices: Use of Synchronization Primitives | This vulnerability occurs when an Enterprise JavaBeans (EJB) component improperly uses thread synchronization primitives, violating the EJB specification's design principles. |
| CWE-591 | Sensitive Data Storage in Improperly Locked Memory | This vulnerability occurs when an application stores sensitive information, like passwords or encryption keys, in system memory that isn't properly secured from being written to disk. If the memory isn't locked, the operating system's virtual memory manager can swap it to a page or swap file, leaving the data exposed on the storage drive where attackers could potentially recover it. |
| CWE-609 | Double-Checked Locking | Double-checked locking is an insufficient synchronization pattern where a program checks a resource's state, acquires a lock, and checks the state again before initialization, failing to guarantee thread safety across all systems. |
| CWE-663 | Use of a Non-reentrant Function in a Concurrent Context | This vulnerability occurs when a program uses a function that is not safe for reentrancy within a concurrent environment, such as multi-threaded code or signal handlers. If another thread or signal handler interrupts and calls the same function, it can corrupt shared data, cause crashes, or create unpredictable behavior. |
| CWE-667 | Improper Locking | This vulnerability occurs when a program fails to correctly acquire or release a lock on a shared resource, such as a file, database record, or memory location. This improper synchronization allows other processes or threads to interfere, leading to corrupted data, crashes, or unpredictable behavior. |
| CWE-689 | Permission Race Condition During Resource Copy | This vulnerability occurs when a system copies a file or resource but delays setting its final permissions until the entire copy operation is finished. During the copy process, the resource remains exposed with default or overly permissive access, creating a temporary window where unauthorized users or processes could read, modify, or delete it. |
| CWE-764 | Multiple Locks of a Critical Resource | This vulnerability occurs when a critical resource, such as a file, data structure, or connection, is locked more times than the software logic intended, putting the system into an unstable or unresponsive state. |
| CWE-765 | Multiple Unlocks of a Critical Resource | This vulnerability occurs when a critical resource, like a lock or semaphore, is unlocked more times than it was locked, putting the system into an unexpected and potentially unstable state. |
| CWE-820 | Missing Synchronization | This vulnerability occurs when multiple parts of your application (like threads or processes) use the same resource—such as a variable, file, or data structure—without proper coordination to control who accesses it and when. |
| CWE-821 | Incorrect Synchronization | This vulnerability occurs when multiple parts of a program, such as threads or processes, access a shared resource like a variable, file, or data structure without proper coordination, leading to a race condition. |
| CWE-828 | Signal Handler with Functionality that is not Asynchronous-Safe | This weakness occurs when a program's signal handler contains code that is not asynchronous-safe. This means the handler can be interrupted or can corrupt shared data, leading to unpredictable program behavior. |
| CWE-831 | Signal Handler Function Associated with Multiple Signals | This vulnerability occurs when a single function is registered to handle multiple different operating system signals, creating potential race conditions if that function isn't carefully designed. |
| CWE-832 | Unlock of a Resource that is not Locked | This vulnerability occurs when a program tries to unlock a resource, such as a mutex or semaphore, that is not currently in a locked state. |
| CWE-833 | Deadlock | Deadlock occurs when two or more threads or processes become permanently stuck, each waiting for the other to release a shared resource like a lock or mutex, preventing any of them from progressing. |
| CWE-1400 | Comprehensive Categorization for Software Assurance Trends |
Vulnerability Mapping Notes
Usage: Prohibited
Reasons: Category
Rationale:
This entry is a Category. Using categories for mapping has been discouraged since 2019. Categories are informal organizational groupings of weaknesses that can help CWE users with data aggregation, navigation, and browsing. However, they are not weaknesses in themselves [REF-1330].
Comment:
See member weaknesses of this category.