Page History

UNDER CONSTRUCTION

When accessing a bit-field, a thread may inadvertently access a separate bit-field in adjacent memory. This is because compilers are required to store multiple adjacent bit-fields in one storage unit whenever they fit. Consequently, data races may exist not just on a bit-field accessed by multiple threads but also on other bit-fields sharing the same byte or word.   A similar problem is discussed in CON00-C. Avoid race conditions with multiple threads, but the issue described by this rule can be harder to The problem is difficult to diagnose because it may not be obvious that the same memory location is being modified by multiple threads.

...

Another approach is to insert a non-bit-field member between any two bit-fields to ensure that each bit-field is the only one accessed within its storage unit. This technique effectively guarantees that no two bit-fields are accessed simultaneously.

Noncompliant Code Example (

...

bit-field)

Adjacent bit-fields may be stored in a single memory location. Consequently, modifying adjacent bit-fields in different threads is undefined behavior, as shown in this noncompliant code example:.

struct multi_threaded_flagsMultiThreadedFlags {
  unsigned int flag1 : 2;
  unsigned int flag2 : 2;
};

structMultiThreadedFlags multi_threaded_flags flags;

intvoid thread1(void *arg) {
  flags.flag1 = 1;
  return 0;
}

intvoid thread2(void *arg) {
  flags.flag2 = 2;
  return 0;
}

The C Standard, 3.14, paragraph 3 [ISO/IEC 9899:2011], states:

...

For example, the following instruction sequence is possible:.

Thread 1: register 0 = flags
Thread 1: register 0 &= ~mask(flag1)
Thread 2: register 0 = flags
Thread 2: register 0 &= ~mask(flag2)
Thread 1: register 0 |= 1 << shift(flag1)
Thread 1: flags = register 0
Thread 2: register 0 |= 2 << shift(flag2)
Thread 2: flags = register 0

Compliant Solution (

...

bit-field,

...

C++11 and later, mutex)

This compliant solution protects all accesses of the flags with a mutex, thereby preventing any data races:.

#include <threads.h><mutex>
 
struct multi_threaded_flagsMultiThreadedFlags {
  unsigned int flag1 : 2;
  unsigned int flag2 : 2;
};

struct mtf_mutexMtfMutex {
  struct multi_threaded_flags MultiThreadedFlags s;
  mtx_tstd::mutex mutex;
};

structMtfMutex mtf_mutex flags;

intvoid thread1(void *arg) {
  if (thrd_success != mtx_lock(&flags.mutex)) {
    /* Handle error */
  }std::lock_guard<std::mutex> lk(flags.mutex);
  flags.s.flag1 = 1;
  if (thrd_success != mtx_unlock(&flags.mutex)) {
    /* Handle error */
  }
  return 0;
}
 
intvoid thread2(void *arg) {
  if (thrd_success != mtx_lock(&std::lock_guard<std::mutex> lk(flags.mutex)) {;
    /* Handle error */
  }
  flags.s.flag2 = 2;
  if (thrd_success != mtx_unlock(&flags.mutex)) {
    /* Handle error */
  }
  return 0;
}

Compliant Solution (

...

C++11)

In this compliant solution, two threads simultaneously modify two distinct non-bit-field members of a structure. Because the members occupy different bytes in memory, no concurrency protection is required.

struct multi_threaded_flagsMultiThreadedFlags {
  unsigned char flag1;
  unsigned char flag2;
};
 
struct multi_threaded_flags MultiThreadedFlags flags;
 
intvoid thread1(void *arg) {
  flags.flag1 = 1;
  return 0;
}

intvoid thread2(void *arg) {
  flags.flag2 = 2;
  return 0;
}

Unlike C99, C11 explicitly defines earlier versions of the standard, C++11 and later explicitly define a memory location and provides provide the following note in subclause 3.14.2 in [intro.memory] paragraph 4 [ISO/IEC 9899:201114882-2014]:

NOTE 1 Two threads of execution can update and access separate memory locations without interfering with each other.[Note: Thus a bit-field and an adjacent non-bit-field are in separate memory locations, and therefore can be concurrently updated by two threads of execution without interference.  The same applies to two bit-fields, if one is declared inside a nested struct declaration and the other is not, or if the two are separated by a zero-length bit-field declaration, or if they are separated by a non-bit-field declaration.  It is not safe to concurrently update two bit-fields in the same struct if all fields between them are also bit-fields of non-zero width.  – end note]

It is almost certain that flag1 and flag2 are stored in the same word. Using a compiler that conforms to C99 or earlier versions of the standard, if both assignments occur on a thread-scheduling interleaving that ends with both stores occurring after one another, it is possible that only one of the flags will be set as intended, and the other flag will contain its previous value , because both members are represented by the same word, which is the smallest unit the processor can work on. Before the changes made to the C++ Standard for C11C++11, there were no guarantees that these flags could be modified concurrently.

...

Although the race window is narrow, an assignment or an expression can evaluate improperly because of misinterpreted data resulting in a corrupted running state or unintended information disclosure.

Automated Detection

Related Vulnerabilities

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

Related Guidelines

Bibliography

...

...

Image Modified Image Modified Image Modified