CertC++-CON43¶

Do not allow data races in multithreaded code

Required inputs: IR

When multiple threads can read or modify the same data, use synchronization techniques to avoid software flaws that can lead to security vulnerabilities. Data races can often result in abnormal termination or denial of service, but it is possible for them to result in more serious vulnerabilities. The C Standard, section 5.1.2.4, paragraph 25 [ ISO/IEC 9899:2011], says:

The execution of a program contains a data race if it contains two conflicting actions in different threads, at least one of which is not atomic, and neither happens before the other. Any such data race results in undefined behavior.

Noncompliant Code Example

Assume this simplified code is part of a multithreaded bank system. Threads call credit() and debit() as money is deposited into and withdrawn from the single account. Because the addition and subtraction operations are not atomic, it is possible that two operations can occur concurrently, but only the result of one would be saved-despite declaring the account_balance volatile. For example, an attacker can credit the account with a sum of money and make a large number of small debits concurrently. Some of the debits might not affect the account balance because of the race condition, so the attacker is effectively creating money.

static volatile int account_balance;

void debit(int amount) {
  account_balance -= amount;
}

void credit(int amount) {
  account_balance += amount;
}

Compliant Solution (Mutex)

This compliant solution uses a mutex to make credits and debits atomic operations. All credits and debits will now affect the account balance, so an attacker cannot exploit the race condition to steal money from the bank. The mutex is created with the mtx_init() function. The presence of the mutex makes declaring account_balance volatile unnecessary.

#include <threads.h>

static int account_balance;
static mtx_t account_lock;
 
int debit(int amount) {
  if (mtx_lock(&account_lock) == thrd_error) {
    return -1;   /* Indicate error to caller */
  }
  account_balance -= amount;
  if (mtx_unlock(&account_lock) == thrd_error) {
    return -1;   /* Indicate error to caller */
  }
  return 0;   /* Indicate success */
}

int credit(int amount) {
  if (mtx_lock(&account_lock) == thrd_error) {
    return -1;   /* Indicate error to caller */
  }
  account_balance += amount;
  if (mtx_unlock(&account_lock) == thrd_error) {
    return -1;   /* Indicate error to caller */
  }
  return 0;   /* Indicate success */
}
 
int main(void) {
  if(mtx_init(&account_lock, mtx_plain) == thrd_error) {
    /* Handle error */
  }
  /* ... */
}

Compliant Solution (Atomic)

This compliant solution uses an atomic variable to synchronize credit and debit operations. All credits and debits will now affect the account balance, so an attacker cannot exploit the race condition to steal money from the bank. The atomic integer does not need to be initialized because default (zero) initialization of an atomic object with static or thread-local storage is guaranteed to produce a valid state. The += and -= operators behave atomically when used with an atomic variable.

#include <stdatomic.h>

atomic_int account_balance;

void debit(int amount) {
  account_balance -= amount;
}

void credit(int amount) {
  account_balance += amount;
}

Noncompliant Code Example (Double-Fetch)

This noncompliant code example illustrates Xen Security Advisory CVE-2015-8550 / XSA-155 In this example, the following code is vulnerable to a data race where the integer referenced by ps could be modified by a second thread that ran between the two reads of the variable.

#include <stdio.h>

void doStuff(int *ps) {
  switch (*ps) {
    case 0: { printf("0"); break; }
    case 1: { printf("1"); break; }
    case 2: { printf("2"); break; }
    case 3: { printf("3"); break; }
    case 4: { printf("4"); break; }
    default: { printf("default"); break; }
  }
}

Even though there is only one read of the *ps variable in the source code, the compiler is permitted to produce object code that performs multiple reads of the memory location. This is permitted by the "as-if" principle, as explained by section 5.1 of the [C99 Rationale 2003]:

The /as if/ principle is invoked repeatedly in this Rationale. The C89 Committee found that describing various aspects of the C language, library, and environment in terms of concrete models best serves discussion and presentation. Every attempt has been made to craft these models so that implementations are constrained only insofar as they must bring about the same result, /as if/ they had implemented the presentation model; often enough the clearest model would make for the worst implementation.

Implementation Details (GCC)

This code produces two reads of the *ps value using GCC 4.8.4 on x86, as well as GCC 5.3.0 on x86-64 ( Compiler-Introduced Double-Fetch Vulnerabilities - Understanding XSA-155).

Noncompliant Code Example (Volatile)

The data race can be disabled by declaring the data to be volatile, because the volatile keyword forces the compiler to not produce two reads of the data. However, this violates CON02-C. Do not use volatile as a synchronization primitive.

#include <stdio.h>

void doStuff(volatile int *ps) {
  switch (*ps) {
    case 0: { printf("0"); break; }
    case 1: { printf("1"); break; }
    case 2: { printf("2"); break; }
    case 3: { printf("3"); break; }
    case 4: { printf("4"); break; }
    default: { printf("default"); break; }
  }
}

Compliant Solution (C11, Atomic)

Declaring the data to be atomic also forces the compiler to produce only one read of the data.

#include <stdio.h>
#include <stdatomic.h>

void doStuff(atomic_int *ps) {
  switch (atomic_load(ps)) {
    case 0: { printf("0"); break; }
    case 1: { printf("1"); break; }
    case 2: { printf("2"); break; }
    case 3: { printf("3"); break; }
    case 4: { printf("4"); break; }
    default: { printf("default"); break; }
  }
}

Compliant Solution (C11, Fences)

The bug was actually resolved by erecting fences around the switch statement.

#include <stdio.h>
#include <stdatomic.h>

void doStuff(int *ps) {
  atomic_thread_fence(memory_order_acquire);
  switch (*ps) {
    case 0: { printf("0"); break; }
    case 1: { printf("1"); break; }
    case 2: { printf("2"); break; }
    case 3: { printf("3"); break; }
    case 4: { printf("4"); break; }
    default: { printf("default"); break; }
  }
  atomic_thread_fence(memory_order_release);
}

Risk Assessment

Race conditions caused by multiple threads concurrently accessing and modifying the same data can lead to abnormal termination and denial-of-service attacks or data integrity violations.

Recommendation	Severity	Likelihood	Remediation Cost	Priority	Level
CON43-C	Medium	Probable	High	P4	L3

Related Guidelines

Taxonomy	Taxonomy item	Relationship
CWE 2.11	CWE-366, Race condition within a thread	2017-07-07: CERT: Exact

Bibliography

[ ISO/IEC 9899:2011]	5.1.2.4, "Multi-threaded Executions and Data Races" 7.17.2, "Initialization"
[C99 Rationale 2003]
[ Dowd 2006]	Chapter 13, "Synchronization and State"
[ Plum 2012]
[ Seacord 2013]	Chapter 8, "File I/O"

Excerpt from SEI CERT C++ Coding Standard [https://cmu-sei.github.io/secure-coding-standards/sei-cert-c-coding-standard/rules/concurrency-con/con43-c], Copyright (C) 1995-2026 Carnegie Mellon University. See section 9.4. "3rd-Party Licenses" in the documentation for full details.

Possible Messages

Key	Text	Severity	Disabled
multiple_lock_add	Lock is acquired while it is already locked.	None	False
non_recursive_lock_add	Non-recursive lock is acquired while it is already locked.	None	False
removed_nonexisting_lock	Lock is released, although it is not currently locked.	None	False
unbalanced_locks_path	Different control flow paths have different sets of locks.	None	False
unbalanced_locks_routine	Routine may return with different lock set than it is entered with ({in_set} vs {out_set}).	None	False

Options¶

This rule shares the following common options: exclude_in_macros, exclude_messages_in_system_headers, excludes, extend_exclude_to_macro_invocations, includes, justification_checker, languages, post_processing, provider, report_at, severity
The following places define options that affect this rule: Stylechecks, Analysis-GlobalOptions

access_kinds¶

access_kinds : set[bauhaus.ir.LIR_Class_Name] = {'Reading_Operand_Interface', 'Writing_Operand_Interface'}

Access kinds (e.g. Reading_Operand_Interface, Writing_Operand_Interface, Address_Operand_Interface).

allow_c11_atomics¶

allow_c11_atomics : bool = True

If set, do not report races on C11 atomic variables.

allow_volatile_sig_atomic_t¶

allow_volatile_sig_atomic_t : bool = False

If set, do not report races on variables of type volatile sig_atomic_t.

debug_output¶

debug_output : bool = False

Option to provide diagnostic output.

enter_critical_functions¶

enter_critical_functions

Type: set[bauhaus.analysis.config.QualifiedName]

Default: {'EnterCriticalSection', 'mtx_lock', 'pthread_mutex_lock', 'std::_Mutex_base::lock', 'std::mutex::lock'}

Set of function names to enter a critical region.

enter_critical_macros¶

enter_critical_macros : set[bauhaus.analysis.config.MacroName] = set()

Set of macro names to enter a critical region (macros must expand to asm() statement).

excluded_routines¶

excluded_routines : set[bauhaus.analysis.config.QualifiedName] = set()

Set of functions that should be excluded from check.

excluded_subgraphs¶

excluded_subgraphs : set[bauhaus.analysis.config.QualifiedName] = set()

Set of entry functions to subgraphs that should be excluded as subgraph from check.

exit_critical_functions¶

exit_critical_functions

Type: set[bauhaus.analysis.config.QualifiedName]

Default: {'ExitCriticalSection', 'mtx_unlock', 'pthread_mutex_unlock', 'std::_Mutex_base::unlock', 'std::mutex::unlock'}

Set of function names to exit a critical region.

exit_critical_macros¶

exit_critical_macros : set[bauhaus.analysis.config.MacroName] = set()

Set of macro names to exit a critical region (macros must expand to asm() statement).

inspect_pointers¶

inspect_pointers : bool = False

Whether pointer targets should be inspected to detect more global variable uses.

nested_critical_regions¶

nested_critical_regions : bool = True

If set to true, critical regions nest; if set to false, a single exit-critical-region terminates all open critical regions.

output_safe_accesses¶

output_safe_accesses : bool = False

When enabled, outputs not only unsafe variable accesses, but also the safe ones.

partitions¶

partitions : dict[str, dict[str, typing.Any]] = {}

Dict with partition name as key and dict as value. Partitions describe parts of the IR graph that can be run as a task or an interrupt service routine. The partition dict can contain keys as follows:

entries: list of entry functions or this task/isr
functions_passed_to: name of thread creation function. Any function designated by a pointer passed to that function will be considered an entry function.
vectors: list of global variable names with function pointers to entry functions or this task/ISR
guarded: boolean property. Set to True if this task is nonpreemptive and cannot be interrupted by interrupt handlers. Set to False or omit otherwise (default).

The special partition name __interrupts__ will automatically contain all interrupt handlers recorded as Additional_Entries in IR (see compiler toolchain's advanced.main_entries configuration) in addition to any entries specified in its dict.

report_cfg_based_critical_region_issues¶

report_cfg_based_critical_region_issues : bool = False

Report unbalanced lock/unlock pairs within a routine. This has the same intention, but is slightly less strict than the purely syntactic check performed by the rule Parallelism-IncorrectCriticalRegion.

show_identical_access¶

show_identical_access : bool = False

When enabled, outputs variable accesses of same kind (i.e., R/R and W/W).

show_object_number¶

show_object_number : bool = False

Option for debugging (shows internal node numbers). Can be used to generate call graphs for data race visualization.

strict_priorities¶

strict_priorities : bool = False

Set to true if a higher-priority task/ISR can only be preempted by a task/ISR of strictly higher priority. This has the effect that critical regions can be omitted in the highest-priority task/ISR if all accesses are from tasks/ISRs on the same core.

treat_types_as_atomic¶

treat_types_as_atomic : set[typing.Pattern[str] | typing.Tuple[typing.Optional[int], typing.Optional[int], typing.Optional[typing.Pattern[str]]]] = set()

Set of type-patterns. A type-pattern is either a regular expression of a type name, or a triple of (min. alignment, max. size, type name-regex). Each of the triple's components may be None. None is interpreted as general wildcard.

Axivion Suite 7.12.0

Navigation