The product does not lock or does not correctly lock a resource when the product must have exclusive access to the resource.
When a resource is not properly locked, an attacker could modify the resource while it is being operated on by the product. This might violate the product's assumption that the resource will not change, potentially leading to unexpected behaviors.

Primary

Architecture and Design

Implementation

Integrity
Availability
Modify Application Data
DoS: Instability
DoS: Crash, Exit, or Restart

Automated Static Analysis
Automated static analysis, commonly referred to as Static Application Security Testing (SAST), can find some instances of this weakness by analyzing source code (or binary/compiled code) without having to execute it. Typically, this is done by building a model of data flow and control flow, then searching for potentially-vulnerable patterns that connect "sources" (origins of input) with "sinks" (destinations where the data interacts with external components, a lower layer such as the OS, etc.)
High

Architecture and Design
Use a non-conflicting privilege scheme.

Architecture and Design
Implementation
Use synchronization when locking a resource.

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

void f(pthread_mutex_t *mutex) {
pthread_mutex_lock(mutex);

/* access shared resource */

pthread_mutex_unlock(mutex);
}

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.

int f(pthread_mutex_t *mutex) {
int result;
result = pthread_mutex_lock(mutex);if (0 != result)return result;

/* access shared resource */

return pthread_mutex_unlock(mutex);
}

This Java example shows a simple BankAccount class with deposit and withdraw methods.

public class BankAccount {

// variable for bank account balance
private double accountBalance;

// constructor for BankAccount
public BankAccount() {accountBalance = 0;}

// method to deposit amount into BankAccount
public void deposit(double depositAmount) {

double newBalance = accountBalance + depositAmount;accountBalance = newBalance;
}

// method to withdraw amount from BankAccount
public void withdraw(double withdrawAmount) {

double newBalance = accountBalance - withdrawAmount;accountBalance = newBalance;
}

// other methods for accessing the BankAccount object
...
}

However, the deposit and withdraw methods have shared access to the account balance private class variable. This can result in a race condition if multiple threads attempt to call the deposit and withdraw methods simultaneously where the account balance is modified by one thread before another thread has completed modifying the account balance. For example, if a thread attempts to withdraw funds using the withdraw method before another thread that is depositing funds using the deposit method completes the deposit then there may not be sufficient funds for the withdraw transaction.
To prevent multiple threads from having simultaneous access to the account balance variable the deposit and withdraw methods should be synchronized using the synchronized modifier.

public class BankAccount {
...
// synchronized method to deposit amount into BankAccount
public synchronized void deposit(double depositAmount) {...}

// synchronized method to withdraw amount from BankAccount
public synchronized void withdraw(double withdrawAmount) {...}
...
}

An alternative solution is to use a lock object to ensure exclusive access to the bank account balance variable. As shown below, the deposit and withdraw methods use the lock object to set a lock to block access to the BankAccount object from other threads until the method has completed updating the bank account balance variable.

public class BankAccount {
...
// lock object for thread access to methods
private ReentrantLock balanceChangeLock;

// condition object to temporarily release lock to other threads
private Condition sufficientFundsCondition;

// method to deposit amount into BankAccount
public void deposit(double amount) {

// set lock to block access to BankAccount from other threads
balanceChangeLock.lock();try {
double newBalance = balance + amount;balance = newBalance;

// inform other threads that funds are available
sufficientFundsCondition.signalAll();

} catch (Exception e) {...}finally {// unlock lock objectbalanceChangeLock.unlock();}
}

// method to withdraw amount from bank account
public void withdraw(double amount) {

// set lock to block access to BankAccount from other threads
balanceChangeLock.lock();try {
while (balance < amount) {

// temporarily unblock access

// until sufficient funds are available
sufficientFundsCondition.await();
}double newBalance = balance - amount;balance = newBalance;

} catch (Exception e) {...}finally {// unlock lock objectbalanceChangeLock.unlock();}
}...
}

CVE-2022-20141
Chain: an operating system kernel has insufficent resource locking (CWE-413) leading to a use after free (CWE-416).
https://www.cve.org/CVERecord?id=CVE-2022-20141

Insufficient Resource Locking

VNA00-J
Ensure visibility when accessing shared primitive variables

VNA02-J
Ensure that compound operations on shared variables are atomic

LCK00-J
Use private final lock objects to synchronize classes that may interact with untrusted code

SFP19
Missing Lock

Allowed
This CWE entry is at the Base level of abstraction, which is a preferred level of abstraction for mapping to the root causes of vulnerabilities.
Carefully read both the name and description to ensure that this mapping is an appropriate fit. Do not try to 'force' a mapping to a lower-level Base/Variant simply to comply with this preferred level of abstraction.

PLOVER
2006-07-19
Draft 3
2006-07-19

Eric Dalci
Cigital
2008-07-01
updated Potential_Mitigations, Time_of_Introduction

CWE Content Team
MITRE
2008-09-08
updated Relationships, Taxonomy_Mappings

CWE Content Team
MITRE
2010-06-21
updated Demonstrative_Examples

CWE Content Team
MITRE
2010-09-27
updated Description, Name

CWE Content Team
MITRE
2010-12-13
updated Demonstrative_Examples

CWE Content Team
MITRE
2011-06-01
updated Common_Consequences, Relationships, Taxonomy_Mappings

CWE Content Team
MITRE
2012-05-11
updated Demonstrative_Examples, Relationships

CWE Content Team
MITRE
2012-10-30
updated Potential_Mitigations

CWE Content Team
MITRE
2014-07-30
updated Relationships, Taxonomy_Mappings

CWE Content Team
MITRE
2017-11-08
updated Applicable_Platforms

CWE Content Team
MITRE
2019-01-03
updated Relationships, Taxonomy_Mappings

CWE Content Team
MITRE
2020-02-24
updated Relationships

CWE Content Team
MITRE
2021-03-15
updated Demonstrative_Examples

CWE Content Team
MITRE
2023-01-31
updated Description

CWE Content Team
MITRE
2023-04-27
updated Detection_Factors, Relationships

CWE Content Team
MITRE
2023-06-29
updated Mapping_Notes

CWE Content Team
MITRE
2023-10-26
updated Observed_Examples

CWE Content Team
MITRE
2025-12-11
4.19
2025-12-11
updated Weakness_Ordinalities

Martin Sebor
Cisco Systems, Inc.
2010-04-30
Provided Demonstrative Example

Insufficient Resource Locking