CWE-667: Improper Locking
Description
The product does not properly acquire or release a lock on a resource, leading to unexpected resource state changes and behaviors.
Locking is a type of synchronization behavior that ensures that multiple independently-operating processes or threads do not interfere with each other when accessing the same resource. All processes/threads are expected to follow the same steps for locking. If these steps are not followed precisely - or if no locking is done at all - then another process/thread could modify the shared resource in a way that is not visible or predictable to the original process. This can lead to data or memory corruption, denial of service, etc.
- Abstraction
- ClassAn abstract weakness, independent of any specific language or technology.
- Likelihood of exploit
- Not rated by MITRE
- Status
- Draft
Common consequences
- Availability
DoS: Resource Consumption (CPU)
Inconsistent locking discipline can lead to deadlock.
Potential mitigations
- ImplementationLibraries or Frameworks
Use industry standard APIs to implement locking mechanism.
Related weaknesses
Parent weaknesses
Child weaknesses
- CWE-412Unrestricted Externally Accessible Lock
- CWE-413Improper Resource Locking
- CWE-414Missing Lock Check
- CWE-609Double-Checked Locking
- CWE-764Multiple Locks of a Critical Resource
- CWE-765Multiple Unlocks of a Critical Resource
- CWE-832Unlock of a Resource that is not Locked
- CWE-833Deadlock
- CWE-1232Improper Lock Behavior After Power State Transition
- CWE-1233Security-Sensitive Hardware Controls with Missing Lock Bit Protection
- CWE-1234Hardware Internal or Debug Modes Allow Override of Locks