Page History

According to the C Standard Annex J.2 (133) [ISO/IEC 9899:2024], the behavior of a program is undefined when

the value of errno is referred to after a signal occurred other than as the result of calling the abort or raise function and the corresponding signal handler obtained a SIG_ERR return from a call to the signal function.

See undefined behavior 133.

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 or modify 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. The C standard Standard, 7.14.1.1, paragraph 5, makes a special exception for errno in this case, saying the only thing that is allowed to go wrong is that errno takes on 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 completely unrestricted undefined behavior, but the handler, and any code executed after the handler returns, must not depend on the value of errno being meaningful.

...

Noncompliant Code Example

The handler() function in this noncompliant code example attempts to restore default handling for the signal indicated by signum. If the request to set the signal to default can be honored, the signal() function returns the value of the signal handler for the most recent successful call to the signal() function for the specified signal. Otherwise, a value of SIG_ERR is returned and a positive value is stored in errno. Unfortunately, the value of errno is indeterminate because the handler() function is called when an external signal is raised, so any attempt to read errno (for example, by the perror() function) is undefined behavior:

#include <signal.h>
#include <stdlib.h>
#include <string<stdio.h>

typedef void (*pfv)(int);

void handler(int signum) {
  pfv old_handler = signal(signum, SIG_DFL);
  if (old_handler == SIG_ERR) {
    perror("SIGINT handler"); /* undefinedUndefined behavior */
    /* handleHandle error condition */
  }
}

int main(void) {
  pfv old_handler = signal(SIGINT, handler);
  if (old_handler == SIG_ERR) {
    perror("SIGINT handler");
    /* handleHandle error condition */
  }

  /* mainMain code loop */

  return 0EXIT_SUCCESS;
}

The call to perror() from handler() also violates SIG30-C. Call only asynchronous-safe functions within signal handlers.

Compliant Solution

The This compliant solution does not reference errno and does not return from the signal handler if the signal() call fails.:

#include <signal.h>
#include <stdlib.h>
#include <string<stdio.h>

typedef void (*pfv)(int);

void handler(int signum) {
  pfv old_handler = signal(signum, SIG_DFL);
  if (old_handler == SIG_ERR) {
    abort();
  }
}

int main(void) {
  pfv old_handler = signal(SIGINT, handler);
  if (old_handler == SIG_ERR) {
    perror("SIGINT handler");
    /* handleHandle error condition */
  }

  /* mainMain code loop */

  return 0EXIT_SUCCESS;
}

...

Noncompliant Code Example (POSIX)

POSIX is less restrictive than C99 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. This can , which can lead to a situation where a signal handler is handler being executed in between a call to a failed function and the subsequent inspection of errno. Consequently, and 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 that contain containing code that might alter errno; always save the value of errno on entry and restore it before returning.

The signal handler in this non-compliant noncompliant code example alters the value of errno, and as . As a result, it can cause incorrect error handling if executed in between a failed function call and the subsequent inspection of errno.:

#include <stddef<signal.h>
#include <signal<stdlib.h>
#include <errno.h>
#include <sys/wait.h>

void reaper(int signum) {
  errno = 0;
  for (;;) {
    int rc = waitpid(-1, NULL, WNOHANG);
    if ( (0 == rc) || (-1 == rc && EINTR != errno)) ){
      break;
    }
  }
  if (ECHILD != errno) {
    /* handleHandle error */
  }
}

int main(void) {
  struct sigaction act;
  act.sa_handler = reaper;
  act.sa_flags = 0;
  if (sigemptyset(&act.sa_mask) != 0) {
    /* handleHandle error */
  }
  if (sigaction(SIGCHLD, &act, NULL) != 0) {
    /* handleHandle error */
  }

  /* ... */

  return 0EXIT_SUCCESS;
}

Compliant Solution (POSIX)

The This compliant solution saves and restores the value of errno in the signal handler.:

#include <stddef<signal.h>
#include <signal<stdlib.h>
#include <errno.h>
#include <sys/wait.h>

void reaper(int signum) {
  interrno_t save_errno = errno;
  errno = 0;
  for (;;) {
    int rc = waitpid(-1, NULL, WNOHANG);
    if ( (0 == rc) || (-1 == rc && EINTR != errno)) ){
      break;
    }
  }
  if (ECHILD != errno) {
    /* handleHandle error */
  }
  errno = save_errno;
}

int main(void) {
  struct sigaction act;
  act.sa_handler = reaper;
  act.sa_flags = 0;
  if (sigemptyset(&act.sa_mask) != 0) {
    /* handleHandle error */
  }
  if (sigaction(SIGCHLD, &act, NULL) != 0) {
    /* handleHandle error */
  }

  /* ... */

  return 0EXIT_SUCCESS;
}

Risk Assessment

Referencing indeterminate values can result in of errno is undefined behavior.

Automated Detection

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)

...

Bibliography

References

...

...

...

...

...

...

Image Added Image Added Image Added function"ERR31-C. Don't redefine errno      12. Error Handling (ERR)       13. Miscellaneous (MSC)