Page History

A signal handler should not reassert its desire to handle its own signal. This is often done on nonpersistent platforms; that platforms—that is, platforms that, upon receiving a signal, reset the disposition for the signal to default before calling the bound signal handler. Calling signal() under these conditions presents a race condition. See SIG01-C. Understand implementation-specific details regarding signal handler persistence.

A signal handler may call signal() only if it does not need to be asynchronous-safe. (In other words, all relevant signals are masked so that the handler cannot be interrupted.)

...

POSIX defines the sigaction() function, which assigns handlers to signals like such as signal() but also allows the caller to explicitly set persistence. Consequently, the sigaction() function can be used to eliminate the race window on nonpersistent operating systems.

...

Although the handler in this example does not call signal(), it could do so safely because the signal is masked , and the handler cannot be interrupted. If the same handler is installed for more than one signal number, the signals must be masked explicitly in act.sa_mask to ensure that the handler cannot be interrupted because the system masks only the signal being delivered.

...

SIG34-EX1: On a machine with persistent signal handlers, it is safe for a handler to modify the behavior for its own signal. Behavior modification would include having the signal be ignored, reset to default behavior, or handled by a different handler. A handler assigning itself to its own signal is also safe , as because it is a no-op. Because multiple invocations of its signal will merely cause it to "interrupt itself," the handler is impervious to a race condition until it manages to reassign its signal.

...

Automated Detection

Related Vulnerabilities

Search for vulnerabilities resulting from the violation of this rule on the CERT website.

...

...