Sending a uncaught signal to a thread to terminate it is not recommended as it kills the entire process as opposed to killing just the individual thread.Calling the signal()
function in a multithreaded program is undefined behavior. (See undefined behavior 135.)
Noncompliant Code Example
This code uses the pthread_killnoncompliant code example invokes the signal()
function to send a SIGKILL signal to the created thread. The thread receives the signal and the entire process is terminated. from a multithreaded program:
Code Block | ||
---|---|---|
| ||
int main(int argc, char* argv[]){
pthread_t thread;
pthread_create(&thread, NULL, func, 0);
pthread_kill(thread, SIGKILL);
/* May run a few more lines until the signal kills the process */
return 0;
}
void func(void *foo){
/* Execution of thread */
}
|
Compliant Solution
This code instead uses the pthread_cancel()
to terminate the thread. In the thread function we set the cancel type to asynchronous, so as to ensure an immediate cancel. If desired, the cancel type can be left as the default type of deferred, where the thread will not terminate until it reaches a cancellation point.
| |||
#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 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_bool
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_bool flag = ATOMIC_VAR_INIT(false);
int func(void *data) {
while (!flag) {
/* ... */
} | ||||
Code Block | ||||
| ||||
int main(int argc, char* argv[]){ pthread_t thread; pthread_create(&thread, NULL, func, (void*)0); sleep(1); pthread_cancel(thread); /* Continues */ return 0; } voidint funcmain(void) *foo){ pthread_setcanceltype(PTHREAD_CANCEL_ASYNCHRONOUSthrd_t tid; if (thrd_success != thrd_create(&tid, func, NULL); )) { /* Handle error */ } /* ... */ /* Set Executionflag ofwhen threaddone */ } flag = true; 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
Using signals as described has the simple consequence of terminating the process, which is clearly undesired. However there is no other direct riskMixing signals and threads causes undefined behavior.
Rule | Severity | Likelihood | Remediation Cost | Priority | Level |
---|
POS44-C
low
unlikely
low
P3
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 | ||||||
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" |
...