CWE-667: Improper Locking

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.

Consequences

• Availability: DoS: Resource Consumption (CPU)

How to prevent it

• Implementation: Use industry standard APIs to implement locking mechanism.

Recent advisories

• GHSA-567q-5qvw-pf92 — filelock: On Windows an oplock on a soft lock's marker holds SoftFileLock.acquire() past its timeout and blocks the stale break
• GHSA-6hcq-hmm3-jj3c — Spring MVC and WebFlux has Server Sent Event stream corruption
• CVE-2025-43510 — A memory corruption issue was addressed with improved lock state checking.
• GHSA-m2v9-w374-5hj9 — vyper default functions don't respect nonreentrancy keys
• GHSA-3hg2-r75x-g69m — Vyper has incorrect re-entrancy lock when key is empty string
• GHSA-vr8j-hgmm-jh9r — Denial of service by double-checked locking in openssl-src
• GO-2022-0830 — Denial of Service in Gitea
• GHSA-h67m-xg8f-fxcf — Deadlock in mutually recursive `tf.function` objects
• CVE-2021-1782 — A race condition was addressed with improved locking.
• GHSA-q4hg-rmq2-52q9 — Improper Locking in Apache Tomcat

All advisories for CWE-667