CWE-831: Signal Handler Function Associated with Multiple Signals

Extended Description

While sometimes intentional and safe, when the same function is used to handle multiple signals, a race condition could occur if the function uses any state outside of its local declaration, such as global variables or non-reentrant functions, or has any side effects. An attacker could send one signal that invokes the handler function; in many OSes, this will typically prevent the same signal from invoking the handler again, at least until the handler function has completed execution. However, the attacker could then send a different signal that is associated with the same handler function. This could interrupt the original handler function while it is still executing. If there is shared state, then the state could be corrupted. This can lead to a variety of potential consequences depending on context, including denial of service and code execution. Another rarely-explored possibility arises when the signal handler is only designed to be executed once (if at all). By sending multiple signals, an attacker could invoke the function more than once. This may generate extra, unintended side effects. A race condition might not even be necessary; the attacker could send one signal, wait until it is handled, then send the other signal.

Code Examples & CVEs

Demonstrative Examples

This code registers the same signal handler function with two different signals.

BadC

void handler (int sigNum) {...}                      int main (int argc, char* argv[]) {signal(SIGUSR1, handler)signal(SIGUSR2, handler)}

This code registers the same signal handler function with two different signals (CWE-831). If those signals are sent to the process, the handler creates a log message (specified in the first argument to the program) and exits.

The handler function uses global state (globalVar and logMessage), and it can be called by both the SIGHUP and SIGTERM signals. An attack scenario might follow these lines:

BadC

char *logMessage;                      void handler (int sigNum) {                         syslog(LOG_NOTICE, "%s\n", logMessage);free(logMessage);                            /* artificially increase the size of the timing window to make demonstration of this weakness easier. */                                                        sleep(10);exit(0);                      }                      int main (int argc, char* argv[]) {                         logMessage = strdup(argv[1]);                            /* Register signal handlers. */                                                        signal(SIGHUP, handler);signal(SIGTERM, handler);                            /* artificially increase the size of the timing window to make demonstration of this weakness easier. */                                                        sleep(10);                      }

Source-backed guidance

Additional facts reviewed against primary or authoritative security sources.

Detect imprecise mappings involving CWE-831

Review mappings to CWE-831, Signal Handler Function Associated with Multiple Signals, with MITRE's mapping and navigation criteria. Flag any selection that points to a View or Category, remains at a higher abstraction than the available evidence supports, or ignores relevant parent, child, peer, and alternative entries. Treat those findings as mapping-quality defects, correct them before publication, and retain the comparison trail for repeatable audits.

CWE Mapping and Navigation Guidance — MITRE CWE

Prevent CWE-831 through an SSDF control plan

Use NIST SSDF practices to make prevention of CWE-831, Signal Handler Function Associated with Multiple Signals, an explicit development outcome. Translate the CWE definition into security requirements and design constraints, choose safer implementation patterns and toolchain checks, and define acceptance evidence before release. Feed every confirmed occurrence back into the requirements, design review, and coding rules so the same root cause is removed across the product rather than patched in one location.

NIST SP 800-218 Secure Software Development Framework — National Institute of Standards and Technology

Triage CWE-831 against known exploitation evidence

Use CISA's Known Exploited Vulnerabilities catalog to test whether a vulnerability mapped to CWE-831, Signal Handler Function Associated with Multiple Signals, has evidence of exploitation in the wild. Confirm the CVE-to-CWE root-cause mapping independently before attaching the example, then capture the affected product, required action, and remediation deadline. A missing KEV match is not evidence that the weakness is unexploited, and a KEV entry must not be generalized to every occurrence of this CWE.

Known Exploited Vulnerabilities Catalog — Cybersecurity and Infrastructure Security Agency

Use MITRE taxonomy anchors to review Signal Handler Function Associated with Multiple Signals

Recorded impacts include DoS: Crash, Exit, or Restart, Execute Unauthorized Code or Commands, Read Application Data, Gain Privileges or Assume Identity, and Bypass Protection Mechanism; related weaknesses include CWE-364. Use these source-defined anchors to turn CWE-831 into implementation, review, and verification checks for the affected component.

CWE-831: Signal Handler Function Associated with Multiple Signals — MITRE CWE

Validate CWE-831 with root-cause mapping checks

Apply MITRE's root-cause mapping quick tips to CWE-831, Signal Handler Function Associated with Multiple Signals. Confirm the finding describes the causal weakness rather than an impact or attack pattern, compare the abstraction and mapping notes with plausible alternatives, and have a second reviewer challenge the selection. Preserve the evidence and reasoning so recurring defects can be measured against one consistent identifier.

CVE to CWE Root Cause Mapping Quick Tips — MITRE CWE

Frequently Asked Questions

What is CWE-831: Signal Handler Function Associated with Multiple Signals?+

CWE-831: Signal Handler Function Associated with Multiple Signals is a Common Weakness Enumeration (CWE) entry maintained by MITRE. The product defines a function that is used as a handler for more than one signal. While sometimes intentional and safe, when the same function is used to handle multiple signals, a race condition could occur if the function uses any state outside of its local declaration, such as global variables or non-reentrant functions, or has any side effects. An attacker could send one signal that invokes the handler function; in many OSes, this will typically prevent the same signal from invoking the handler again, at least until the handler function has completed execution. However, the attacker could then send a different signal that is associated with the same handler function. This could interrupt the original handler function while it is still executing. If there is shared state, then the state could be corrupted. This can lead to a variety of potential consequences depending on context, including denial of service and code execution. Another rarely-explored possibility arises when the signal handler is only designed to be executed once (if at all). By sending multiple signals, an attacker could invoke the function more than once. This may generate extra, unintended side effects. A race condition might not even be necessary; the attacker could send one signal, wait until it is handled, then send the other signal.

What are the security consequences of Signal Handler Function Associated with Multiple Signals?+

If exploited, CWE-831 (Signal Handler Function Associated with Multiple Signals) it can compromise Availability, Integrity, Confidentiality, Access Control and Other, leading to outcomes such as DoS: Crash, Exit, or Restart, Execute Unauthorized Code or Commands, Read Application Data, Gain Privileges or Assume Identity, Bypass Protection Mechanism and Varies by Context.

Which programming languages are affected by Signal Handler Function Associated with Multiple Signals?+

CWE-831 commonly affects Not Language-Specific. Note that weaknesses are often language-agnostic patterns, so secure coding practices apply broadly.

What is the difference between a CWE and a CVE?+

A CWE (Common Weakness Enumeration) like CWE-831 describes a category of software weakness — the underlying flaw type. A CVE (Common Vulnerabilities and Exposures) identifies a specific, real-world vulnerability in a particular product. In short, a CWE is the kind of mistake, and a CVE is an instance of that mistake being found in software.

CWE-831: Signal Handler Function Associated with Multiple Signals

Extended Description

Technical Details

Applicable To

Security Consequences

Scope

Impact

Mitigation Strategies

Detection Methods