Keep signal handlers minimal and use only functions that are safe to call in that context. Do not perform complex memory, I/O, or shared-state operations inside the handler, because they can interrupt code already using the same resources. Set a flag, return quickly, and let normal program flow do the work after the signal is handled.
Why signal handlers must stay reentrant-safe
A signal handler can interrupt code that is already inside a library call, allocator, lock, or I/O routine. If the handler calls a non-reentrant function, it may collide with the interrupted execution path and corrupt internal state, deadlock, or produce undefined behaviour. The safest pattern is to do the minimum work in the handler and defer anything complex until normal flow resumes.
Reentrancy is the key constraint, not just “short code.” A function can be small and still unsafe if it touches shared buffers, global state, static storage, or locks that may already be in use at the moment the signal arrives. That is why the usual advice is to treat the handler as an emergency notification point, not as a place to run application logic.
For developers, this means the design choice comes first: decide what the handler is allowed to do, then build the rest of the program around that limit. In practice, that usually means setting a flag, writing to a pipe or other signal-safe notification path, and letting the main event loop or worker thread pick up the work later.
What makes a function unsafe inside a handler?
The dangerous cases are usually the ones that assume uninterrupted execution. Memory allocation, formatted I/O, logging, locale-aware routines, and functions that acquire locks are common examples because they often depend on internal state that is not protected against interruption by the same process. If a signal lands while that state is half-updated, a second call from the handler can step into a partially completed operation.
This risk is especially easy to miss when the function is “normally harmless” in ordinary code. A routine may behave correctly in the main thread, yet still be unsafe in a handler because the issue is not correctness in isolation, but whether it can safely interrupt itself or a related runtime path. That is why developers should think in terms of execution context, not just function name.
A practical rule is to separate signal-safe notification from deferred processing. The handler should capture only the fact that something happened, or at most store a value in a simple shared location that the rest of the program can read later. Everything that requires allocation, parsing, formatting, or coordinated state updates belongs outside the handler.
Safer patterns for handling signals without reentrancy bugs
The cleanest approach is to make the handler nearly stateless. Use an atomic or otherwise signal-safe flag, then return immediately. Your normal control flow can check that flag at safe points and perform the real work where full program services are available again.
When the program needs richer notification, route the signal into a mechanism designed for deferred processing, such as an event loop wakeup, self-pipe pattern, or equivalent platform-specific bridge. That keeps the handler itself simple while still giving the application a way to react promptly without invoking unsafe functions at interrupt time.
It also helps to review any library callbacks or utility wrappers you call from the handler. Developers sometimes avoid obvious non-reentrant functions but still call through helper layers that eventually use them. If the call chain is not explicitly signal-safe, treat it as unsafe until proven otherwise.
Risk and Threat Considerations
A bad signal-handler design can create reliability failures that are hard to reproduce because they depend on timing. The same bug may appear as a crash in one run, a hang in another, and silent state corruption in a third. That makes signal-related reentrancy defects especially costly to diagnose in production systems.
Failure mechanism: The handler interrupts code that is already inside a non-reentrant routine, then re-enters the same shared state, lock, or runtime path before the first execution has completed.
Impact: The process can deadlock, corrupt memory or internal bookkeeping, leak resources, or terminate unpredictably, especially under load or during error handling when signals and shared state are more likely to overlap.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
CIS Controls v8, NIST SP 800-53 Rev 5 and OWASP ASVS set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| CIS Controls v8 | CIS-8 — Audit Log Management | Signal handlers should avoid unsafe logging paths and deferred processing needs visible error handling. |
| Recommendation — Route signal events through safe logging and monitoring paths, not directly from the handler. | ||
| NIST SP 800-53 Rev 5 | AU-6 — Audit Review, Analysis, and Reporting | Deferred signal handling depends on trustworthy event capture and later review of abnormal termination or state changes. |
| SI-7 — Software, Firmware, and Information Integrity | Reentrancy failures can corrupt runtime state and cause integrity loss in process execution. | |
| Recommendation — Review signal-related events after the handler returns using normal audit workflows. Validate that signal-driven paths cannot corrupt process state or bypass integrity checks. | ||
| OWASP ASVS | V15 — Secure Coding and Architecture | The question is about safe coding structure and avoiding unsafe execution in an interrupt context. |
| V16 — Security Logging and Error Handling | Signal handlers often surface as abrupt failures that need safe error and event handling outside the handler. | |
| Recommendation — Design interrupt handlers to use minimal, signal-safe code paths and defer complex work. Capture signal conditions safely and handle recovery logic outside the handler. | ||
Practitioner Guidance
What to verify: Audit every function reachable from the handler, including helpers and wrappers, and confirm that it is safe in an interrupt context. If you cannot prove signal safety, move the work out of the handler.
Decision rule: If the handler needs more than setting a flag or triggering a minimal notification, treat that as a design smell and defer the work to the main execution path or a dedicated worker.
Common mistake: Developers often assume a function is safe because it is frequently used elsewhere in the codebase. Handler safety is a separate property, and ordinary unit tests rarely expose timing-dependent reentrancy failures.
Practitioner takeaway: The safest signal handler is usually the one that does almost nothing, because correctness depends less on speed than on avoiding re-entry into code that was never designed to be interrupted.
Related resources from NHI Mgmt Group
- Guide: CWE Top 25 Guide
- How can developers prevent path traversal using a Windows UNC share path?
- How do developers prevent invoking a process using visible sensitive information?
- How do developers prevent using the same seed in a pseudo-random number generator?
- Signal Handler Use of a Non-reentrant Function