CWE-662: Improper Synchronization
Description
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 properly synchronize these actions, which might cause simultaneous accesses of this resource by multiple threads or processes.
Submission Date :
April 11, 2008, midnight
Modification Date :
2023-10-26 00:00:00+00:00
Organization :
MITRE
Extended Description
Synchronization refers to a variety of behaviors and mechanisms that allow two or more independently-operating processes or threads to ensure that they operate on shared resources in predictable ways that do not interfere with each other. Some shared resource operations cannot be executed atomically; that is, multiple steps must be guaranteed to execute sequentially, without any interference by other processes. Synchronization mechanisms vary widely, but they may include locking, mutexes, and semaphores. When a multi-step operation on a shared resource cannot be guaranteed to execute independent of interference, then the resulting behavior can be unpredictable. Improper synchronization could lead to data or memory corruption, denial of service, etc.
Example - 1
The following function attempts to acquire a lock in order to perform operations on a shared resource. 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.
// /* access shared resource *///
pthread_mutex_lock(mutex);pthread_mutex_unlock(mutex);void f(pthread_mutex_t *mutex) {}
return result;
// /* access shared resource *///
int result;result = pthread_mutex_lock(mutex);if (0 != result)return pthread_mutex_unlock(mutex);int f(pthread_mutex_t *mutex) {}
Example - 2
The following code intends to fork a process, then have both the parent and child processes print a single line. One might expect the code to print out something like: 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:
// /* Make timing window a little larger... *///
putc(counter, stdout);fflush(stdout);sleep(1);char * word;int counter;for (word = string; counter = *word++; ) {}
exit(-2);
print("child\n");
print("PARENT\n");
pid_t pid;pid = fork();if (pid == -1) {}else if (pid == 0) {}else {}exit(0);static void print (char * string) {}int main(void) {}
Related Weaknesses
This table shows the weaknesses and high level categories that are related to this weakness. These relationships are defined to give an overview of the different insight to similar items that may exist at higher and lower levels of abstraction.
CWE-362: Concurrent Execution using Shared Resource with Improper Synchronization ('Race Condition')
CWE-366: Race Condition within a Thread
CWE-543: Use of Singleton Pattern Without Synchronization in a Multithreaded Context
CWE-567: Unsynchronized Access to Shared Data in a Multithreaded Context
CWE-663: Use of a Non-reentrant Function in a Concurrent Context
CWE-664: Improper Control of a Resource Through its Lifetime
CWE-667: Improper Locking
CWE-691: Insufficient Control Flow Management
CWE-764: Multiple Locks of a Critical Resource
CWE-820: Missing Synchronization
CWE-821: Incorrect Synchronization
CWE-833: Deadlock
CWE-1058: Invokable Control Element in Multi-Thread Context with non-Final Static Storable or Member Element
CWE-1096: Singleton Class Instance Creation without Proper Locking or Synchronization
Visit http://cwe.mitre.org/ for more details.