Page History

When multiple threads must access or make modifications to a common variable, they may also inadvertently access other variables adjacent in memory. This is an artifact of variables being stored compactly, with one byte possibly holding multiple variables, and is a common optimization on word-addressed machines. Bit-fields are especially prone to this behavior because compliers are allowed to store multiple bit-fields in one addressable byte or word. This implies that race conditions 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 variable bit-field accessed by multiple threads , but also on other variables bit-fields sharing the same byte or word address..  A similar problem is discussed in CON43-C. Do not allow data races in multithreaded code, but the issue described by this rule can be harder to diagnose because it may not be obvious that the same memory location is being modified by multiple threads.

One approach for preventing data races A common tool for preventing race conditions in concurrent programming is the to use a mutex. When properly observed by all threads, a mutex can provide safe and secure access to a common variable, however, it guarantees nothing regarding other variables shared object. However, mutexes provide no guarantees with regard to other objects that might be accessed when a common variable is accessed. Unfortunately the mutex is not controlled by the accessing thread. Unfortunately, there is no portable way to determine which adjacent variables bit-fields may be stored along with a certain variablethe desired bit-field.

A better Another approach is to embed a concurrently-accessed variable inside a union, along with a long variable, or at least some padding to ensure that the concurrent variable is the only element to be accessed at that address. This would effectively guarantee that no other variables are accessed or modified when the concurrent variable is accessed or modifiedinsert 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 In this noncompliant code example, two executing threads simultaneously access two separate members of a global struct.:

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

struct multi_threaded_flags flags;

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

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

...

The C Standard, 3.17, paragraph 3 [ISO/IEC 9899:2024], states

Note 2 to entry: A bit-field and an adjacent non-bit-field member are in separate memory locations. The same applies to two bit-fields, if one is declared inside a nested structure 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 member declaration. It is not safe to concurrently update two non-atomic bit-fields in the same structure if all members declared between them are also (nonzero-length) bit-fields, no matter what the sizes of those intervening bit-fields happen to be.

For example, the following sequence of events can occur.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

Even though each thread is modifying a separate bit-field, they are both modifying the same location in memory.  This is the same problem discussed in POS00-C. Avoid race conditions with multiple threads but is harder to diagnose, because it is not obvious at first glance that the same memory location is being modified.

Compliant Solution (Bit-field, C11, Mutex

...

)

This compliant solution protects all accesses of the flags with a mutex, thereby preventing any thread scheduling interleaving from occurring. In addition, the flags are declared volatile to ensure that the compiler will not attempt to move operations on them outside the mutex. Finally, the flags are embedded in a union alongside a long int, and a static assertion guarantees that the flags do not occupy more space than the long. This prevents any data not checked by the mutex from being accessed or modified with the bit fields.data races:

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

unionstruct mtf_protectmutex {
  struct multi_threaded_flags s;
  longmtx_t paddingmutex;
};

static_assert(sizeof(long) >= sizeof(struct multi_threaded_flags));

struct mtf_mutex {
  union mtf_protect u;
  pthread_mutex_t mutex;
};

struct mtf_mutex flags;

void thread1(void) {
  pthread_mutexstruct mtf_mutex flags;

int thread1(void *arg) {
  if (thrd_success != mtx_lock(&flags.mutex)) {
    /* Handle error */
  }
  flags.s.flag1 = 1;
  if (thrd_success != mtx_unlock(&flags.mutex)) {
    /* Handle error */
  }
  return 0;
}
 
int thread2(void *arg) {
  if (thrd_success != mtx_lock(&flags.mutex);) {
    /* Handle error */
  }
  flags.u.s.flag1flag2 = 12;
  if pthread_mutex(thrd_success != mtx_unlock(&flags.mutex)) {
    /* Handle error */
  }
  return 0;
}

Compliant Solution (C11)

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_flags {
  unsigned char flag1;
  unsigned char flag2;
};

void thread2(void 
struct multi_threaded_flags flags;
 
int thread1(void *arg) {
  pthread_mutex_lock(&flags.mutex);flags.flag1 = 1;
  return 0;
}

int thread2(void *arg) {
  flags.u.s.flag2 = 2;
  pthread_mutex_unlock(&flags.mutex) return 0;
}

Unlike C99, C11 and C23 explicitly define a memory location and provides the following note in subclause 3.17 paragraph 2 [ISO/IEC 9899:2024]:

Note 1 to entry: Two threads of execution can update and access separate memory locations without interfering with each other.

It is almost certain that flag1 and flag2 are stored in the same word. Using a compiler that conforms to C99 or earlier, 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. 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 were made to the C Standard for C11, there were no guarantees that these flags could be modified concurrentlyStatic assertions are discussed in detail in DCL03-C. Use a static assertion to test the value of a constant expression.

Risk Assessment

Although the race window is narrow, having an assignment or an expression can evaluate improperly because of misinterpreted data can result 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.

References

...

Bibliography

...

...

...

Image Added Image Added Image Added1999|AA. C References#ISO/IEC 9899-1999]\] Section 6.7.2.1, "Structure and union specifiers"POS31-C. Do not unlock or destroy another thread's mutex      50. POSIX (POS)      POS33-C. Do not use vfork()