Calling the signal()
function in a multithreaded program is undefined behavior according to C11 (Section 7.14.1.1, paragraph 7).This rule is a specific instance of SIG02-C. Avoid using signals to implement normal functionality.. (See undefined behavior 135.)
Noncompliant Code Example
This code raises a signal within a child thread. This is meant to terminate the program, but results in undefined behavior.noncompliant code example invokes the signal()
function from a multithreaded program:
Code Block | ||||
---|---|---|---|---|
| ||||
void func(void *data#include <signal.h> #include <stddef.h> #include <threads.h> volatile sig_atomic_t flag = 0; void handler(int signum) { flag = 1; } /* ... Runs until user sends SIGUSR1 */ int if (thread_should_exitfunc(void *data) { while raise( SIGTERM!flag); // Undefined! { } /* ... */ } return 0; } int main(void) { int result;signal(SIGUSR1, handler); /* Undefined behavior */ thrd_t threadtid; int result; if ((resultthrd_success != thrd_create(&tid, func, NULL)) != thrd_success) { /* Handle Errorerror */ } /* ... */ 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 code terminates the child thread rather than raising a signal. This has the same effect as the noncompliant code example, but is well-defined in C11.compliant solution uses an object of type atomic_bool
to indicate when the child thread should terminate its loop:
Code Block | ||||
---|---|---|---|---|
| ||||
void func(void *data) { /* ... */ if (thread_should_exit#include <stdatomic.h> #include <stdbool.h> #include <stddef.h> #include <threads.h> atomic_bool flag = ATOMIC_VAR_INIT(false); int func(void *data) { while thrd_exit(0); // OK(!flag) { } /* ... */ } return 0; } int main(void) { int result; thrd_t threadtid; int result; if ((resultthrd_success != thrd_create(&tid, func, NULL)) != thrd_success) { /* Handle Errorerror */ } /* ... */ /* Set flag when done */ flag = true; return 0; } |
...
Exceptions
CON37:EX0: Platforms -C-EX1: Implementations such as POSIX that provide defined behavior when multithreaded programs use custom signal handlers are exempt from this rule . This would include POSIX, for example[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 | ||||||
---|---|---|---|---|---|---|---|---|---|
Astrée |
| stdlib-use-signal | Fully checked | ||||||
CodeSonar |
| BADFUNC.SIGNAL | Use of signal | ||||||
Coverity |
| MISRA C 2012 Rule 21.5 | Over-constraining | ||||||
Cppcheck Premium |
| premium-cert-con37-c | Fully implemented | ||||||
Helix QAC |
| C5021 C++5022 | |||||||
Klocwork |
| MISRA.STDLIB.SIGNAL | |||||||
LDRA tool suite |
| 44 S | Enhanced enforcement | ||||||
Parasoft C/C++test |
| CERT_C-CON37-a | The signal handling facilities of <signal.h> shall not be used |
Bibliography
...
PC-lint Plus |
| 586 | Fully supported | ||||||
Polyspace Bug Finder |
| CERT C: Rule CON37-C | Checks for signal call in multithreaded program (rule fully covered) | ||||||
RuleChecker |
| stdlib-use-signal | Fully checked |
Bibliography
[IEEE Std 1003.1-2013] | XSH 2.9.1, "Thread Safety" |
...