CertC-POS49¶

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

Required inputs: IR

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 may exist not just on a variable accessed by multiple threads but also on other variables sharing the same byte or word address. This recommendation is a specific instance of CON32-C. Prevent data races when accessing bit-fields from multiple threads using POSIX threads.

A common tool for preventing race conditions in concurrent programming is the mutex. When properly observed by all threads, a mutex can provide safe and secure access to a common variable; however, it guarantees nothing with regard to other variables that might be accessed when a common variable is accessed.

Unfortunately, there is no portable way to determine which adjacent variables may be 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 technique would effectively guarantee that no other variables are accessed or modified when the concurrent variable is accessed or modified.

Noncompliant Code Example (Bit-field)

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;

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

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

Although this code appears to be harmless, it is 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, 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 CON43-C. Do not allow data races in multithreaded code but is harder to diagnose because it is not immediately obvious that the same memory location is being modified.

Compliant Solution (Bit-field)

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

struct multi_threaded_flags {
  volatile unsigned int flag1 : 2;
  volatile unsigned 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) {
  int result;
  if ((result = pthread_mutex_lock(&flags.mutex)) != 0) {
    /* Handle error */
  }
  flags.u.s.flag1 = 1;
  if ((result = pthread_mutex_unlock(&flags.mutex)) != 0) {
    /* Handle error */
  }
}

void thread2(void) {
  int result;
  if ((result = pthread_mutex_lock(&flags.mutex)) != 0) {
    /* Handle error */
  }
  flags.u.s.flag2 = 2;
  if ((result = pthread_mutex_unlock(&flags.mutex)) != 0) {
    /* Handle error */
  }
}

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.

Rule	Severity	Likelihood	Remediation Cost	Priority	Level
POS49-C	Medium	Probable	Medium	P8	L2

Bibliography

[ ISO/IEC 9899:2011]

Subclause 6.7.2.1, "Structure and Union Specifiers"

Excerpt from SEI CERT C Coding Standard: Rules for Developing Safe, Reliable, and Secure Systems (2016 Edition) and SEI CERT C Coding Standard [https://cmu-sei.github.io/secure-coding-standards/sei-cert-c-coding-standard/rules/posix-pos/pos49-c], Copyright (C) 1995-2026 Carnegie Mellon University. See section 9.4. "3rd-Party Licenses" in the documentation for full details.

Possible Messages

Key	Text	Severity	Disabled
prevent-data-races	When data must be accessed by multiple threads, provide a mutex and guarantee no adjacent data is also accessed.	None	False

Options¶

This rule shares the following common options: exclude_in_macros, exclude_messages_in_system_headers, excludes, extend_exclude_to_macro_invocations, includes, justification_checker, languages, post_processing, provider, report_at, severity
The following places define options that affect this rule: Stylechecks, Analysis-GlobalOptions

access_kinds¶

access_kinds : set[bauhaus.ir.LIR_Class_Name] = {'Reading_Operand_Interface', 'Writing_Operand_Interface'}

Access kinds (e.g. Reading_Operand_Interface, Writing_Operand_Interface, Address_Operand_Interface).

allow_c11_atomics¶

allow_c11_atomics : bool = True

If set, do not report races on C11 atomic variables.

allow_volatile_sig_atomic_t¶

allow_volatile_sig_atomic_t : bool = False

If set, do not report races on variables of type volatile sig_atomic_t.

debug_output¶

debug_output : bool = False

Option to provide diagnostic output.

enter_critical_functions¶

enter_critical_functions

Type: set[bauhaus.analysis.config.QualifiedName]

Default: {'EnterCriticalSection', 'mtx_lock', 'pthread_mutex_lock', 'std::_Mutex_base::lock', 'std::mutex::lock'}

Set of function names to enter a critical region.

enter_critical_macros¶

enter_critical_macros : set[bauhaus.analysis.config.MacroName] = set()

Set of macro names to enter a critical region (macros must expand to asm() statement).

excluded_routines¶

excluded_routines : set[bauhaus.analysis.config.QualifiedName] = set()

Set of functions that should be excluded from check.

excluded_subgraphs¶

excluded_subgraphs : set[bauhaus.analysis.config.QualifiedName] = set()

Set of entry functions to subgraphs that should be excluded as subgraph from check.

exit_critical_functions¶

exit_critical_functions

Type: set[bauhaus.analysis.config.QualifiedName]

Default: {'ExitCriticalSection', 'mtx_unlock', 'pthread_mutex_unlock', 'std::_Mutex_base::unlock', 'std::mutex::unlock'}

Set of function names to exit a critical region.

exit_critical_macros¶

exit_critical_macros : set[bauhaus.analysis.config.MacroName] = set()

Set of macro names to exit a critical region (macros must expand to asm() statement).

inspect_pointers¶

inspect_pointers : bool = False

Whether pointer targets should be inspected to detect more global variable uses.

nested_critical_regions¶

nested_critical_regions : bool = True

If set to true, critical regions nest; if set to false, a single exit-critical-region terminates all open critical regions.

output_safe_accesses¶

output_safe_accesses : bool = False

When enabled, outputs not only unsafe variable accesses, but also the safe ones.

partitions¶

partitions : dict[str, dict[str, typing.Any]] = {}

Dict with partition name as key and dict as value. Partitions describe parts of the IR graph that can be run as a task or an interrupt service routine. The partition dict can contain keys as follows:

entries: list of entry functions or this task/isr
functions_passed_to: name of thread creation function. Any function designated by a pointer passed to that function will be considered an entry function.
vectors: list of global variable names with function pointers to entry functions or this task/ISR
guarded: boolean property. Set to True if this task is nonpreemptive and cannot be interrupted by interrupt handlers. Set to False or omit otherwise (default).

The special partition name __interrupts__ will automatically contain all interrupt handlers recorded as Additional_Entries in IR (see compiler toolchain's advanced.main_entries configuration) in addition to any entries specified in its dict.

report_cfg_based_critical_region_issues¶

report_cfg_based_critical_region_issues : bool = False

Report unbalanced lock/unlock pairs within a routine. This has the same intention, but is slightly less strict than the purely syntactic check performed by the rule Parallelism-IncorrectCriticalRegion.

show_identical_access¶

show_identical_access : bool = True

When enabled, outputs variable accesses of same kind (i.e., R/R and W/W).

show_object_number¶

show_object_number : bool = False

Option for debugging (shows internal node numbers). Can be used to generate call graphs for data race visualization.

strict_priorities¶

strict_priorities : bool = False

Set to true if a higher-priority task/ISR can only be preempted by a task/ISR of strictly higher priority. This has the effect that critical regions can be omitted in the highest-priority task/ISR if all accesses are from tasks/ISRs on the same core.

treat_types_as_atomic¶

treat_types_as_atomic : set[typing.Pattern[str] | typing.Tuple[typing.Optional[int], typing.Optional[int], typing.Optional[typing.Pattern[str]]]] = set()

Set of type-patterns. A type-pattern is either a regular expression of a type name, or a triple of (min. alignment, max. size, type name-regex). Each of the triple's components may be None. None is interpreted as general wildcard.

Axivion Suite 7.12.0

Navigation