The C99 C Standard provides three functions that cause an application to terminate normally: _Exit()
, exit()
, and quick_exit()
. These are collectively called exit functions. When the exit()
function is called, or control transfers out of the main()
entry point function, functions registered with atexit()
are called (but not at_quick_exit()
). When the quick_exit()
function is used for normal program termination. If more than one call to exit()
is executed by a program, the behavior is undefined. This may occur when functions are registered with atexit()
, a function that causes the functions registered to it to be called with when the program exits. If a function called as a result of being registered with atexit()
has an exit()
call in it there is undefined behavior.
Non-Compliant Code Example
called, functions registered with at_quick_exit()
(but not atexit()
) are called. These functions are collectively called exit handlers. When the _Exit()
function is called, no exit handlers or signal handlers are called.
Exit handlers must terminate by returning. It is important and potentially safety-critical for all exit handlers to be allowed to perform their cleanup actions. This is particularly true because the application programmer does not always know about handlers that may have been installed by support libraries. Two specific issues include nested calls to an exit function and terminating a call to an exit handler by invoking longjmp
.
A nested call to an exit function is undefined behavior. (See undefined behavior 182.) This behavior can occur only when an exit function is invoked from an exit handler or when an exit function is called from within a signal handler. (See SIG30-C. Call only asynchronous-safe functions within signal handlers.)
If a call to the longjmp()
function is made that would terminate the call to a function registered with atexit()
, the behavior is undefined.
Noncompliant Code Example
In this noncompliant code example, the exit1()
and exit2()
functions are registered by atexit()
to perform required cleanup upon program termination. However, if some_condition
evaluates to true, exit()
is called a second time, resulting in undefined behaviorIn this example the function exit1() is registered by atexit() so upon program termination exit1() is called and certain cleanup and maintenance functions can occur. If some failure case <expr> evaluates as true though the program attempts to fully exit before the cleanup code can be processed. In these cases where expr evaluates to true exit() will be called twice and the behavior is undefined. Some compilers will simply ignore the exit() call as it in is a function registered by atexit().
Code Block | ||||
---|---|---|---|---|
| ||||
#include <stdio.h> #include <stdlib.h> void exit1(void) { if(expr) exit() /* ... Cleanup code ... */ return; } void exit2(void) { extern int some_condition; if (some_condition) { //clean up and ready program for closing* ... More cleanup code ... */ exit(0); } ...return; } int main (void) { if (atexit(exit1); ... != 0) { /* Handle error */ } if (atexit(exit2) != 0) { //program code* Handle error */ } /* ... Program exit(); code ... */ return 0; } |
Compliant Code
To have functionality where the program can quit from within a function registered by at_exit() it is necessary to use a function used for abnormal termination such as _Exit() or abort().
_Exit() a c99 defined function is described as follows:
...
Functions registered by the atexit()
function are called in the reverse order from which they were registered. Consequently, if exit2()
exits in any way other than by returning, exit1()
will not be executed. The same may also be true for atexit()
handlers installed by support libraries.
Compliant Solution
A function that is registered as an exit handler by atexit()
must exit by returning, as in this compliant solution:
Code Block | ||||
---|---|---|---|---|
| ||||
#include <stdio<stdlib.h> #include <stdlib.h> #include <stdio.h> #include <stdlib.h> void exit1 void exit1(void) { /* ... Cleanup code ... */ return; } void exit2(void) { extern int some_condition; if (exprsome_condition) { /* ... More _Exit();cleanup code ... */ } return; } int main(void) { if (atexit(exit1) != 0) { //clean up and ready program for closing* Handle error */ } if (atexit(exit2) != 0) { /* Handle error */ } /* ... Program code ... */ return 0; } |
Noncompliant Code Example
In this noncompliant code example, exit1()
is registered by atexit()
so that upon program termination, exit1()
is called. The exit1()
function jumps back to main()
to return, with undefined results.
Code Block | ||||
---|---|---|---|---|
| ||||
#include <stdlib.h> #include <setjmp.h> jmp_buf env; int mainval; void exit1(void) { longjmp(env, 1); } int main(void) { if (atexit(exit1);) != 0) { .../* Handle error */ } if (setjmp(env) //program code== 0) { exit(0); } else { return 0; } |
The call to _Exit() will immediately terminate the program and no undefined behavior will happen like in the non compliant example.
Risk Assessment
}
|
Compliant Solution
This compliant solution does not call longjmp()
but instead returns from the exit handler normally:
Code Block | ||||
---|---|---|---|---|
| ||||
#include <stdlib.h>
void exit1(void) {
return;
}
int main(void) {
if (atexit(exit1) != 0) {
/* Handle error */
}
return 0;
}
|
Risk Assessment
Terminating a call to an exit handler in any way other than by returning is undefined behavior and may result in abnormal program termination or other unpredictable behavior. It may also prevent other registered handlers from being invokedMultiple calls to exit in code are likely to be rare but if exist can cause denial of service and abnormal program termination.
Rule | Severity | Likelihood | Remediation Cost | Priority | Level |
---|---|---|---|---|---|
ENV32-C |
1 (low)
1 (unlikely)
3 (low)
P3
L3
References
Medium | Likely | Medium | P12 | L1 |
Automated Detection
Tool | Version | Checker | Description | ||||||
---|---|---|---|---|---|---|---|---|---|
Astrée |
| user_defined bad-function bad-function-use | Soundly supported | ||||||
Axivion Bauhaus Suite |
| CertC-ENV32 | |||||||
CodeSonar |
| BADFUNC.ABORT | Use of abort | ||||||
Compass/ROSE | Can detect violations of this rule. In particular, it ensures that all functions registered with | ||||||||
Cppcheck Premium | 24.9.0 | premium-cert-env32-c | Partially Implemented | ||||||
Helix QAC |
| DF4856, DF4857, DF4858 | |||||||
Klocwork |
| CERT.EXIT.HANDLER_TERMINATE | |||||||
LDRA tool suite |
| 122 S 7 S | Enhanced enforcement | ||||||
Parasoft C/C++test |
| CERT_C-ENV32-a | Properly define exit handlers | ||||||
| CERT C: Rule ENV32-C | Checks for abnormal termination of exit handler (rule fully covered) | |||||||
RuleChecker |
| bad-function bad-function-use | Supported |
Related Vulnerabilities
Search for vulnerabilities resulting from the violation of this rule on the CERT website.
Related Guidelines
Key here (explains table format and definitions)
Taxonomy | Taxonomy item | Relationship |
---|---|---|
CERT C Secure Coding Standard | SIG30-C. Call only asynchronous-safe functions within signal handlers | Prior to 2018-01-12: CERT: Unspecified Relationship |
ISO/IEC TR 24772:2013 | Structured Programming [EWD] | Prior to 2018-01-12: CERT: Unspecified Relationship |
ISO/IEC TR 24772:2013 | Termination Strategy [REU] | Prior to 2018-01-12: CERT: Unspecified Relationship |
CWE 2.11 | CWE-705, Incorrect Control Flow Scoping | 2017-07-10: CERT: Rule subset of CWE |
CERT-CWE Mapping Notes
Key here for mapping notes
CWE-705 and ENV32-C
CWE-705 = Union( ENV32-C, list) where list =
- Improper control flow besides a non-returning exit handler
...
\[[ISO/IEC 9899-1999|AA. C References#ISO/IEC 9899-1999]\] Section 7.20.4.3, "The exit function" Wiki Markup