[metadata]
id = "CON01-C"
type = "recommendation"
category = "CON"
number = 1
title = "Acquire and release synchronization primitives in the same module, at the same level of abstraction"
description = """
All locking and unlocking of mutexes should be performed in the same module and
at the same level of abstraction. Failure to follow this recommendation can lead
to some lock or unlock operations not being executed by the multithreaded
program as designed, eventually resulting in deadlock, race conditions, or other
securityvulnerabilities, depending on the mutex type. A common consequence of
improper locking is for a mutex to be unlocked twice, via two calls
tomtx_unlock(). This can cause the unlock operation to return errors. In the
case of recursive mutexes, an error is returned only if the lock count is 0
(making the mutex available to other threads) and a call tomtx_unlock()is made.
In this noncompliant code example for a simplified multithreaded banking system,
imagine an account with a required minimum balance. The code would need to
verify that all debit transactions are allowable. Suppose a call is made
todebit()asking to withdraw funds that would
bringaccount_balancebelowMIN_BALANCE, which would result in two calls
tomtx_unlock(). In this example, because the mutex is defined statically, the
mutex type isimplementation-defined.
"""
severity = "Low"
likelihood = "Probable"
priority = "P4"
level = "L3"
cert_version = "2016 Edition (Wiki)"
last_modified = "May 20, 2025"
[rules.cert_c.CON01-C]
enabled = true
[references]
wiki = "https://wiki.sei.cmu.edu/confluence/display/c/CON01-C.+Acquire+and+release+synchronization+primitives+in+the+same+module%2C+at+the+same+level+of+abstraction"