Calling the signal()
function in a multithreaded program is undefined behavior (see undefined behavior 135).
Noncompliant Code Example
This noncompliant code example invokes the signal()
function from a multithreaded program:
#include <signal.h> #include <threads.h> volatile sig_atomic_t flag = 0; void handler(int signum) { flag = 1; } /* Runs until user sends SIGUSR1 */ int func(void *data) { while (!flag) { /* ... */ } return 0; } int main(void) { signal(SIGUSR1, handler); /* Undefined behavior */ thrd_t tid; if (thrd_success != thrd_create(&tid, func, NULL)) { /* Handle error */ } /* ... */ return 0; }
NOTE: The SIGUSR1
signal value is not defined in the C Standard; consequently, this is not a C-compliant code example.
Compliant Solution
This compliant solution uses an object of type atomic_flag
to indicate when the child thread should terminate its loop:
#include <stdatomic.h> #include <threads.h> atomic_flag flag = ATOMIC_VAR_INIT(0); int func(void *data) { while (!flag) { /* ... */ } return 0; } int main(void) { int result; thrd_t tid; if (thrd_success != thrd_create(&tid, func, NULL)) { /* Handle error */ } /* ... */ /* Set flag when done */ while (!atomic_flag_test_and_set(&flag)) ; /* Continue attempts */ return 0; }
Exceptions
CON37-C-EX1: Implementations such as POSIX that provide defined behavior when multithreaded programs use custom signal handlers are exempt from this rule [IEEE Std 1003.1-2013].
Risk Assessment
Mixing signals and threads causes undefined behavior.
Rule | Severity | Likelihood | Remediation Cost | Priority | Level |
---|---|---|---|---|---|
CON37-C | Low | Probable | Low | P6 | L2 |
Related Vulnerabilities
Search for vulnerabilities resulting from the violation of this rule on the CERT website.
Automated Detection
Tool | Version | Checker | Description |
---|---|---|---|
CodeSonar | 8.1p0 | BADFUNC.SIGNAL | Use of signal |
Parasoft C/C++test | 9.5 | MISRA2012-RULE-21_5_b | Use of signal |
Bibliography
[IEEE Std 1003.1-2013] | XSH 2.9.1, "Thread Safety" |