
According to the C Standard Annex J.2 (133) [ISO/IEC 9899:20112024], the behavior of a program is undefined when
...
A signal handler is allowed to call signal()
, and ;
if that fails, signal()
returns SIG_ERR
and sets errno
to a positive value. However, if the event that caused a signal was external (not the result of the program calling abort()
or raise()
), the only functions the signal handler may call are _Exit()
or abort()
, or it may call signal()
on the signal currently being handled, and ; if signal()
fails, the value of errno
is indeterminate.
This rule is also a special case of SIG31-C. Do not access shared objects in signal handlers. The object designated by errno
is of static storage duration and is not a volatile sig_atomic_t
. As a result, performing any action that would require errno
to be set would normally cause undefined behavior 132. The C Standard, 7.14.1.1, paragraph 5, makes a special exception for errno
in this case, allowing errno
to take on an indeterminate value but specifying that there is no other undefined behavior. This special exception makes it possible to call signal()
from within a signal handler without risking undefined behavior, but the handler, and any code executed after the handler returns, must not depend on the value of errno
being meaningful.
...
POSIX is less restrictive than C about what applications can do in signal handlers. It has a long list of asynchronous-safe functions that can be called. (see See SIG30-C. Call only asynchronous-safe functions within signal handlers.) . Many of these functions set errno
on error, which can lead to a signal handler being executed between a call to a failed function and the subsequent inspection of errno
. Consequently, the value inspected is not the one set by that function but the one set by a function call in the signal handler. POSIX applications can avoid this problem by ensuring that signal handlers containing code that might alter errno
; always save the value of errno
on entry and restore it before returning.
The signal handler in this noncompliant code example alters the value of errno
, and as . As a result, it can cause incorrect error handling if executed between a failed function call and the subsequent inspection of errno
:
...
Referencing indeterminate values of errno
is undefined behavior.
Rule | Severity | Likelihood | Detectable |
---|
Repairable | Priority | Level | |
---|---|---|---|
ERR32-C | Low | Unlikely | Yes |
Yes | P3 | L3 |
Automated Detection
Tool | Version | Checker | Description | ||||||
---|---|---|---|---|---|---|---|---|---|
Astrée |
| chained-errno-function-calls errno-test-after-wrong-call | Supported | ||||||
Axivion Bauhaus Suite |
| CertC-ERR32 | |||||||
Compass/ROSE |
Could detect violations of this rule by looking for signal handlers that themselves call | |||||||||
Coverity |
| MISRA C 2012 Rule 22.8 MISRA C 2012 Rule 22.9 MISRA C 2012 Rule 22.10 | Implemented | ||||||
Cppcheck Premium |
| premium-cert-err32-c | |||||||
Helix QAC |
| C2031 DF4781, DF4782, DF4783 | |||||||
Klocwork |
| MISRA.INCL.SIGNAL.2012 | |||||||
LDRA tool suite |
| 44 S | Enhanced enforcement | ||||||
Parasoft C/C++test |
| CERT_C-ERR32-b | Properly define signal handlers | ||||||
| CERT C: Rule ERR32-C | Checks for misuse of errno in a signal handler (rule fully covered) | |||||||
RuleChecker |
| chained-errno-function-calls errno-test-after-wrong-call | Supported | ||||||
Security Reviewer - Static Reviewer |
| C34 | Fully implemented |
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 |
CERT C Secure Coding Standard | SIG31-C. Do not access shared objects in signal handlers |
Prior to 2018-01-12: CERT: Unspecified Relationship |
Bibliography
...
...