Page History

When multiple threads must access or make modifications to a common variable, they may also

When accessing an object, a thread may inadvertently access other variables a seperate object in adjacent memory. This is an artifact of variables objects being stored compactly, with one byte possibly holding multiple variables, and .  This is a common optimization on word-addressed machines. Bit-fields are especially prone to this behavior because compilers are allowed to store multiple bit-fields in one addressable byte or word. Consequently, data races may exist not just on a variable an object accessed by multiple threads but also on other variables objects sharing the same byte or word address.

One tool approach for preventing data races in concurrent programming is the mutex. When properly observed by all threads, a mutex can provide safe and secure access to a common variableobject. However, it mutexs provide no guarantees nothing with regard to other variables objects that might be accessed when the mutex is not controlled by the accessing thread.

...

Another approach is to embed a concurrently accessed variable object inside a union , along with alongside a long variable, or at least some object or other padding to ensure that the concurrent variable object is the only element to be one accessed at that address. This technique would effectively guarantee that no other variables two object are accessed or modified when the concurrent variable is accessed or modifiedsimultaneously.

Noncompliant Code Example (C99)

In this noncompliant code example, two threads simultaneously modify two distinct members of a structstructure:

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

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

...

Even though each thread is modifying a separate object, they may be modifying the same word in memory. A similar problem is discussed in CON00-C. Avoid race conditions with multiple threads, but this example can be harder to diagnose because it is not immediately obvious that the same memory location is being modified.

Compliant Solution (C11)

The same code is compliant when run on a C11-compliant platform. Unlike C99, C11 explicitly defines a memory location and provides the following note in subclause 3.14.2 [ISO/IEC 9899:2011]:

NOTE 1 Two threads of execution can update and access separate memory locations without interfering with each other.

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:

...

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, C11, Mutex)

This compliant solution protects all accesses of the flags with a mutex, thereby preventing any data races. Finally, the flags are embedded in a union alongside a long, and a static assertion guarantees that the flags do not occupy more space than the long. This technique prevents any data not checked by the mutex from being accessed or modified with the bit-fields on platforms that do not comply with C11.

...

Static 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 evaluate improperly because of misinterpreted data can result 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.

Bibliography

...