CON00-C. Avoid race conditions with multiple threads

When multiple threads can read or modify the same data, use synchronization techniques to avoid software flaws that can lead to security vulnerabilities. Concurrency problems can often result in abnormal termination or denial of service, but it is possible for them to result in more serious vulnerabilities.

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. Note that 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)

This compliant solution uses a Microsoft Windows critical section object to make operations involving account_balance atomic [MSDN].  In Windows parlance, a mutex is used to provide synchronization across process boundaries, and a critical section is restricted to providing synchronization across threads of the same process.

#include <Windows.h>

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

int debit(int amount) {
  EnterCriticalSection(&account_lock);
  account_balance -= amount;
  LeaveCriticalSection(&account_lock);

  return 0;   /* Indicate success */
}

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() function.

#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);
}

This compliant solution uses the EXP12-EX1 exception in EXP12-C. Do not ignore values returned by functions because the result of InterlockedAdd() is irrelevant to all subsequent calculations. 

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.

Automated Detection

Related Vulnerabilities

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

Related Guidelines

Bibliography