POS32-C. Include a mutex when using bit-fields in a multi-threaded environment

Bit-fields may be used to declare struct members that use only a specified number of bits. If multiple threads are accessing or making modifications to different bit-fields, a race condition may be present, because the architecture may not be able to modify only the bits to which the member currently being modified may refer. As a result, a mutex protecting all bit-fields at the same time must be used.

Non-Compliant Code Example

In the following non-compliant code, two executing threads simultaneously access two separate members of a global struct.

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

struct multi_threaded_flags flags;

void thread1(void) {
  flags.flag1 = 1;
}

void thread2(void) {
  flags.flag2 = 2;
}

Although this appears to be harmless, it is possible (and likely) that flag1 and flag2 are stored in the same byte. 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 equal its previous value. This is because both bit-fields are represented by the same byte, which is the smallest unit the processor can work on.

For example, the following sequence of events can occur.

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-A. 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

This compliant solution protects all usage of the flags with a mutex, preventing an unfortunate thread scheduling interleaving from being able to occur. In addition, the flags are declared volatile to ensure that the compiler will not attempt to move operations on them outside the mutex.

struct multi_threaded_flags {
  volatile int flag1 : 2;
  volatile int flag2 : 2;
  pthread_mutex_t mutex;
};

struct multi_threaded_flags flags;

void thread1(void) {
  pthread_mutex_lock(&flags.mutex);
  flags.flag1 = 1;
  pthread_mutex_unlock(&flags.mutex);
}

void thread2(void) {
  pthread_mutex_lock(&flags.mutex);
  flags.flag2 = 2;
  pthread_mutex_unlock(&flags.mutex);
}

Risk Assessment

Although the race window is narrow, having an assignment or an expression evaluate improperly due to misinterpreted data can possibly result in a corrupted running state or unintended information disclosure.

Related Vulnerabilities

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

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