Page History

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. C11The C Standard, section 5.1.2.45, paragraph 25 35 [ISO/IEC 9899:2024], 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.

...

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. Note that the The presence of the mutex makes declaring account_balance volatile unnecessary.

#include <threads.h>

static int account_balance;
static mtx_t account_lock;

if(mtx_init(&account_lock, mtx_plain) == thrd_error) {
	/* Handle error */
}
/* ... */

 
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 */
}

Compliant Solution (Critical Section, Windows)

...

...

#include <Windows.h>

static int account_balance;
static CRITICAL_SECTION account_lock;
 
/* Must be initialized before use */
InitializeCriticalSection(&account_lock);
/* ... */

int debit(int amount) int main(void) {
  EnterCriticalSectionif(mtx_init(&account_lock);
  account_balance -= amount;
  LeaveCriticalSection(&account_lock);
  return 0;, mtx_plain) == thrd_error) {
    /* IndicateHandle successerror */
}

int credit(int amount) {
  EnterCriticalSection(&account_lock);
  account_balance += amount;
  LeaveCriticalSection(&account_lock);
  return 0;   /* Indicate success }
  /* ... */
}

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 is created with the atomic_init() functiondoes 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;

/* Initialize account_balance */

void debit(int amount) {
  atomic_fetch_sub((volatile atomic_int *)&account_balance, -= amount);
}

void credit(int amount) {
  atomic_fetch_add((volatile atomic_int *)&account_balance, amount);
}

Compliant Solution (Atomic, Windows)

This compliant solution uses the interlocked family of APIs on Windows to provide atomic access to the account_balance variable [MSDN].  Note that account_balance uses the volatile LONG type to match the parameter type expected by InterlockedAdd(), and there is no corresponding interlocked subtraction function, so amount is negated when performing a debit().

#include <Windows.h>

static volatile LONG account_balance;

/* Initialize account_balance */

void debit(int amount) {
  (void)InterlockedAdd(account_balance, -amount);
}

void credit(int amount) {
  (void)InterlockedAdd(account_balance, amount);
}

...

 += 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 can be 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>
#include <stdlib.h>
 
void doStuff(int * ps) {
  printf("NON-VOLATILE");
  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]:

...

#include <stdio.h>
#include <stdlib.h>
 
void doStuff(volatile int * ps) {
  printf("NON-VOLATILE");
  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)

...

#include <stdio.h>
#include <stdlib.h>
#include <stdatomic.h>
 
void doStuff(atomic_int * ps) {
  printf("NON-VOLATILE");
  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)

...

#include <stdio.h>
#include <stdlib.h>
#include <stdatomic.h>
 
void doStuff(int * ps) {
  printf("NON-VOLATILE");
  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);
}

...

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.

Automated Detection

Related Vulnerabilities

Search for vulnerabilities resulting from the violation of this rule on the CERT website.

Related Guidelines

Key here (explains table format and definitions)

Bibliography

...

...

Image Modified Image Modified Image Modified