VariantIncomplete

CWE-828Signal Handler with Functionality that is not Asynchronous-Safe

Category: logic

Description

The product defines a signal handler that contains code sequences that are not asynchronous-safe, i.e., the functionality is not reentrant, or it can be interrupted.

Common consequences· 1

  • Integrity / Confidentiality / Availability — DoS: Crash, Exit, or Restart, Execute Unauthorized Code or Commands
    The most common consequence will be a corruption of the state of the product, possibly leading to a crash or exit. However, if the signal handler is operating on state variables for security relevant libraries or protection mechanisms, the consequences can be far more severe, including protection mechanism bypass, privilege escalation, or information exposure.

Potential mitigations· 2

  • [Implementation, Architecture and Design]
  • [Implementation]Where non-reentrant functionality must be leveraged within a signal handler, be sure to block or mask signals appropriately. This includes blocking other signals within the signal handler itself that may also leverage the functionality. It also includes blocking all signals reliant upon the functionality when it is being accessed or modified by the normal behaviors of the product.

References

  1. https://cwe.mitre.org/data/definitions/828.html

Related by meaning· 6

Nearest entities by semantic similarity across the cs-graph corpus.

CWE
Signal Handler Use of a Non-reentrant Function
CWE
Signal Handler Race Condition
CWE
Use of a Non-reentrant Function in a Concurrent Context
CWE
Dangerous Signal Handler not Disabled During Sensitive Operations
CWE
Signal Handler Function Associated with Multiple Signals
CWE
Concurrent Execution using Shared Resource with Improper Synchronization ('Race Condition')
Sourced from MITRE CWE 4.20. Curated for EU compliance use cases by Adam Lundqvist, Founder at SQUR.