SFP Secondary Cluster: Missing Lock

A product performs a series of non-atomic actions to switch between contexts that cross privilege or other security boundaries, but a race condition allows an attacker...

The product uses double-checked locking to access a resource without the overhead of explicit synchronization, but the locking is insufficient.

The product does not properly acquire or release a lock on a resource, leading to unexpected resource state changes and behaviors.

The product does not lock or does not correctly lock a resource when the product must have exclusive access to the resource.

The product utilizes multiple threads or processes to allow temporary access to a shared resource that can only be exclusive to one process at a time, but it does not ...

A product does not check to see if a lock is present before performing sensitive operations on a resource.

If two threads of execution use a resource simultaneously, there exists the possibility that resources may be used while invalid, in turn making the state of execution...

The product uses a signal handler that introduces a race condition.

The product does not properly synchronize shared data, such as static variables across threads, which can lead to undefined behavior and unpredictable data changes.

The product calls a non-reentrant function in a concurrent context in which a competing code sequence (e.g. thread or signal handler) may have an opportunity to call t...

The product uses the singleton pattern when creating a resource within a multithreaded environment.

CWE identifiers in this view are associated with clusters of Software Fault Patterns (SFPs).