Calling the signal() function in a multithreaded program is undefined behavior, according to the C Standard. (See also undefined behavior 135 of Annex J.)
This rule is a specific instance of SIG02-C. Avoid using signals to implement normal functionality.
Noncompliant Code Example
This noncompliant code example invokes the signal() function from a multithreaded program.
| Code Block | ||||
|---|---|---|---|---|
| ||||
#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! */
thrd_t tid;
if (thrd_success != thrd_create(&tid, func, NULL)) {
/* Handle error */
}
/* ... */
return 0;
} |
Compliant Solution
This compliant solution uses an object of type atomic_flag to indicate when the child thread should terminate its loop.
| Code Block | ||||
|---|---|---|---|---|
| ||||
#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-EX1: Platforms that provide defined behavior when multithreaded programs use custom signal handlers are exempt from this rule. For example, this exception is specified by POSIX Section XSH 2.9.1 Thread-Safety [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.