Improper Synchronization

Draft Class
Structure: Simple
Description

This vulnerability occurs when a multi-threaded or multi-process application allows shared resources to be accessed by multiple threads or processes simultaneously, without proper safeguards to enforce exclusive access.

Extended Description

Synchronization is the set of techniques that prevent multiple threads or processes from interfering with each other when they need to use the same resource, like a variable, file, or memory location. Since many operations on these resources cannot be performed in a single, atomic step, you need mechanisms like locks, mutexes, or semaphores to guarantee that one thread completes its entire sequence of operations before another can begin. Without this coordination, the application's behavior becomes unpredictable and unstable. Improper synchronization directly leads to race conditions, where the final state of the resource depends on the unpredictable timing of thread execution. This can corrupt data, crash the program, create security bypasses, or cause a denial of service. As a developer, you must identify all shared resources in your concurrent code and explicitly protect them with appropriate synchronization primitives to ensure only one thread can access them at a time.

Common Consequences 1
Scope: IntegrityConfidentialityOther

Impact: Modify Application DataRead Application DataAlter Execution Logic

Potential Mitigations 1
Phase: Implementation
Use industry standard APIs to synchronize your code.
Demonstrative Examples 2

ID : DX-24

The following function attempts to acquire a lock in order to perform operations on a shared resource.

Code Example:

Bad
C
c

/* access shared resource /

c
However, the code does not check the value returned by pthread_mutex_lock() for errors. If pthread_mutex_lock() cannot acquire the mutex for any reason, the function may introduce a race condition into the program and result in undefined behavior.
In order to avoid data races, correctly written programs must check the result of thread synchronization functions and appropriately handle all errors, either by attempting to recover from them or reporting them to higher levels.

Code Example:

Good
C
c

/* access shared resource /

c

ID : DX-170

The following code intends to fork a process, then have both the parent and child processes print a single line.

Code Example:

Bad
C
c

/* Make timing window a little larger... /

c
One might expect the code to print out something like:
``` PARENT child ```
However, because the parent and child are executing concurrently, and stdout is flushed each time a character is printed, the output might be mixed together, such as:
``` PcAhRiElNdT [blank line] [blank line] ```
Observed Examples 2
CVE-2021-1782Chain: improper locking (Improper Locking) leads to race condition (Concurrent Execution using Shared Resource with Improper Synchronization ('Race Condition')), as exploited in the wild per CISA KEV.
CVE-2009-0935Attacker provides invalid address to a memory-reading function, causing a mutex to be unlocked twice
Modes of Introduction
Architecture and Design
Implementation
Taxonomy Mapping
  • CERT C Secure Coding
  • CERT C Secure Coding
  • CLASP
  • The CERT Oracle Secure Coding Standard for Java (2011)
  • Software Fault Patterns
Notes
MaintenanceDeeper research is necessary for synchronization and related mechanisms, including locks, mutexes, semaphores, and other mechanisms. Multiple entries are dependent on this research, which includes relationships to concurrency, race conditions, reentrant functions, etc. Improper Synchronization and its children - including Improper Locking, Missing Synchronization, Incorrect Synchronization, and others - may need to be modified significantly, along with their relationships.