CWE-479: Signal Handler Use of a Non-reentrant Function
The product defines a signal handler that calls a non-reentrant function.
Last updated
Overview
Non-reentrant functions are functions that cannot safely be called, interrupted, and then recalled before the first call has finished without resulting in memory corruption. This can lead to an unexpected system state and unpredictable results with a variety of potential consequences depending on context, including denial of service and code execution. Many functions are not reentrant, but some of them can result in the corruption of memory if they are used in a signal handler. The function call syslog() is an example of this. In order to perform its functionality, it allocates a small amount of memory as "scratch space." If syslog() is suspended by a signal call and the signal handler calls syslog(), the memory used by both of these functions enters an undefined, and possibly, exploitable state. Implementations of malloc() and free() manage metadata in global structures in order to track which memory is allocated versus which memory is available, but they are non-reentrant. Simultaneous calls to these functions can cause corruption of the metadata.
Real-world CVEs
2 recorded CVEs are caused by CWE-479 (Signal Handler Use of a Non-reentrant Function). The highest-severity and most recent are shown first. 1 new CWE-479 CVE has been recorded so far in 2026.
Common consequences
What can happen when CWE-479 is exploited.
Execute Unauthorized Code or Commands
Affects: Integrity, Confidentiality, Availability
It may be possible to execute arbitrary code through the use of a write-what-where condition.
Modify Memory, Modify Application Data
Affects: Integrity
Signal race conditions often result in data corruption.
How it happens
When it is introduced
Typically introduced during these phases of the software lifecycle.
Applies to
Languages
How to prevent it
Practical mitigations for CWE-479, grouped by where in the lifecycle they apply.
Require languages or libraries that provide reentrant functionality, or otherwise make it easier to avoid this weakness.
Design signal handlers to only set flags rather than perform complex functionality.
Ensure that non-reentrant functions are not found in signal handlers.
Use sanity checks to reduce the timing window for exploitation of race conditions. This is only a partial solution, since many attacks might fail, but other attacks still might work within the narrower window, even accidentally.
Effectiveness: Defense in Depth
How to detect it
Automated Static Analysis
Automated static analysis, commonly referred to as Static Application Security Testing (SAST), can find some instances of this weakness by analyzing source code (or binary/compiled code) without having to execute it. Typically, this is done by building a model of data flow and control flow, then searching for potentially-vulnerable patterns that connect "sources" (origins of input) with "sinks" (destinations where the data interacts with external components, a lower layer such as the OS, etc.)
Effectiveness: High
Code examples
Illustrative examples from MITRE showing how the weakness appears in code.
In this example, a signal handler uses syslog() to log a message:
Vulnerable example
char *message;Illustrative examples
Real CVEs that MITRE cites as examples of this weakness.
- CVE-2005-0893 — signal handler calls function that ultimately uses malloc()
- CVE-2004-2259 — SIGCHLD signal to FTP server can cause crash under heavy load while executing non-reentrant functions like malloc/free.
Terminology & mappings
Mapped taxonomies
- CLASP: Unsafe function call from a signal handler
- CERT C Secure Coding: Call only asynchronous-safe functions within signal handlers (SIG30-C) — Exact fit
- CERT C Secure Coding: Do not call signal() from within interruptible signal handlers (SIG34-C)
- The CERT Oracle Secure Coding Standard for Java (2011): Never dereference null pointers (EXP01-J)
- Software Fault Patterns: Use of an improper API (SFP3)
Frequently asked questions
Common questions about CWE-479.
- What is CWE-479?
- The product defines a signal handler that calls a non-reentrant function.
- What CVEs are caused by CWE-479?
- 2 recorded CVEs are attributed to CWE-479, including CVE-2026-44011, CVE-2021-26948.
- How do you prevent CWE-479?
- Require languages or libraries that provide reentrant functionality, or otherwise make it easier to avoid this weakness.
- How is CWE-479 detected?
- Automated Static Analysis: Automated static analysis, commonly referred to as Static Application Security Testing (SAST), can find some instances of this weakness by analyzing source code (or binary/compiled code) without having to execute it. Typically, this is done by building a model of data flow and control flow, then searching for potentially-vulnerable patterns that connect "sources" (origins of input) with "sinks" (destinations where the data interacts with external components, a lower layer such as the OS, etc.)
- What are the consequences of CWE-479?
- Exploiting CWE-479 can lead to: Execute Unauthorized Code or Commands, Modify Memory, Modify Application Data.
- Is CWE-479 actively exploited?
- 2 recorded CVEs are caused by CWE-479; none are currently in CISA's KEV catalog of actively exploited flaws.
References
- MITRE CWE definition (CWE-479) (opens in a new tab)
- CWE-479 vulnerabilities on NVD (opens in a new tab)
- Learn: What is a CWE?
Weakness data is sourced from the MITRE CWE catalog (v4.20). CVE associations are aggregated and kept current by RadicalNotion.AI.
Stay ahead of CWE-479
Get alerted the moment a new CWE-479 vulnerability affects your stack, with AI-written analysis, severity context, and remediation guidance.