POS32-C. When data must be accessed by multiple threads, provide a mutex and guarantee no adjacent data is also accessed.

When multiple threads must access or make modifications to a common variable, they may also access variables adjacent in memory to the common variable. This is an artefact of variables being stored compactly, with one byte holding multiple variables, and is a common optimization on word-addressed machines. Bit-fields are especially prone to this behavior, since C is designed to store multiple bit-fields in one addressable byte (or word). So race conditions may exist, not just on a variable accessed by multiple threads, but also on other variables sharing the same byte or word address.

A common means of preventing race conditions in concurrent programming is the mutex. When properly observed by all threads, a mutex may provide safe and secure access to a common variable, it guarantees nothing regarding other variables that might be accessed when a common variable is accessed.

Unfortunately there is no portable way to determine just what adjacent variables are stored along with a certain variable.

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

Non-Compliant Code Example (Bit Field)

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

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. Finally, the flags are embedded in a union alongside a long int, and a static assertion guarantees that the flags do not occupuy more space than the long. This prevents any data not checked by the mutex from being accessed or modified with the bit fields.

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

union mtf_protect {
  struct multi_threaded_flags s;
  long padding;
};

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_mutex_lock(&flags.mutex);
  flags.u.s.flag1 = 1;
  pthread_mutex_unlock(&flags.mutex);
}

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

Static assertions are discussed more thoroughly in DCL03-A. 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 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()