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 sets a signal handler, while also setting a child thread to do work. This results in undefined behavior.noncompliant code example invokes the signal()
function from a multithreaded program:
Code Block | ||||
---|---|---|---|---|
| ||||
#include <signal.h> #include <stddef.h> #include <threads.h> volatile sig_atomic_t flag = 0; void handler(int signum) { flag = 1; } int func(void *data) { /* keep runningRuns until user sends SIGUSR1 */ int func(void *data) { while (!flag) { /* ... */ } return 0; } int main(void) { signal(SIGUSR1, handler); /* Undefined! behavior */ int result; thrd_t tid; 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 dispenses with the signal handler, and compliant solution uses an object of type atomic_flagbool
to indicate when the child thread should terminate its loop.:
Code Block | ||||
---|---|---|---|---|
| ||||
#include <stdatomic.h> #include <stdbool.h> #include <stddef.h> #include <threads.h> atomic_flagbool flag = ATOMIC_VAR_INIT(0false); int func(void *data) { /* keep running until user sends SIGUSR1 */ while (!flag) { /* ... */ } return 0; } int main(void) { int result; thrd_t tid; if ((resultthrd_success != thrd_create(&tid, func, NULL)) != thrd_success) { /* Handle Errorerror */ } /* ... */ /* Set flag when done */ while (!atomic_flag_test_and_set( &flag)) { /* try again */ } = 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 |
Bibliography
...
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 | ||||||
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" |
...