Signal Handler Race Condition
CWE-364
The product uses a signal handler that introduces a race condition.
These issues occur when non-reentrant functions, or state-sensitive actions occur in the signal handler, where they may be called at any time. These behaviors can violate assumptions being made by the regular code that is interrupted, or by other signal handlers that may also be invoked. If these functions are called at an inopportune moment - such as while a non-reentrant function is already running - memory corruption could occur that may be exploitable for code execution. Another signal race condition commonly found occurs when free() is called within a signal handler, resulting in a double free and therefore a write-what-where condition. Even if a given pointer is set to NULL after it has been freed, a race condition still exists between the time the memory was freed and the pointer was set to NULL. This is especially problematic if the same signal handler has been set for more than one signal -- since it means that the signal handler itself may be reentered. There are several known behaviors related to signal handlers that have received the label of signal handler race condition: Shared state (e.g. global data or static variables) that are accessible to both a signal handler and regular code Shared state between a signal handler and other signal handlers Use of non-reentrant functionality within a signal handler - which generally implies that shared state is being used. For example, malloc() and free() are non-reentrant because they may use global or static data structur
We track 9 vulnerabilities of this type. 100% are rated high or critical, and the average CVSS score is 7.9.
How this weakness is prevented
- Requirements: Use a language that does not allow this weakness to occur or provides constructs that make this weakness easier to avoid.
- Architecture and Design: Design signal handlers to only set flags, rather than perform complex functionality. These flags can then be checked and acted upon within the main program loop.
- Implementation: Only use reentrant functions within signal handlers. Also, use validation to ensure that state is consistent while performing asynchronous actions that affect the state of execution.
Latest Signal Handler Race Condition vulnerabilities
- 7.8 High severity
Linux: Use After Free
In the Linux kernel, the following vulnerability has been resolved: zram: fix use-after-free in zram_bvec_write_partial() zram_read_page() picks the sync or async backing device read path based on whether the parent bio is NULL. zram_bvec_write_partial() passe
- 7.8 High severity
Linux: Out-of-bounds Read
In the Linux kernel, the following vulnerability has been resolved: bpf: Free reuseport cBPF prog after RCU grace period. Eulgyu Kim reported the splat below with a repro. [0] The repro sets up a UDP reuseport group with a cBPF prog and replaces it with a new
- 7.8 High severity
Linux: Use After Free
In the Linux kernel, the following vulnerability has been resolved: ALSA: aloop: Fix peer runtime UAF during format-change stop loopback_check_format() may stop the capture side when playback starts with parameters that no longer match a running capture stream
- 7.8 High severity
Linux: Use After Free
In the Linux kernel, the following vulnerability has been resolved: can: isotp: fix tx.buf use-after-free in isotp_sendmsg() isotp_sendmsg() uses only cmpxchg() on so->tx.state to serialize access to so->tx.buf. isotp_release() waits for ISOTP_IDLE via wait_ev
- 8.8 High severity
electron: Use After Free
Electron is a framework for writing cross-platform desktop applications using JavaScript, HTML and CSS. Prior to versions 38.8.6, 39.8.0, 40.7.0, and 41.0.0-beta.8, apps that register an asynchronous session.setPermissionRequestHandler() may be vulnerable to a
- 7.5 High severity
Firefox: Concurrent Execution using Shared Resource with Improper Synchronization
Race condition, use-after-free in the Graphics: WebRender component. This vulnerability was fixed in Firefox 149, Firefox ESR 115.34, Firefox ESR 140.9, Thunderbird 149, and Thunderbird 140.9.
- 8.1 High severity
FreeBSD: Concurrent Execution using Shared Resource with Improper Synchronization
A signal handler in sshd(8) may call a logging function that is not async-signal-safe. The signal handler is invoked when a client does not authenticate within the LoginGraceTime seconds (120 by default). This signal handler executes in the context of the sshd
- 7.0 High severity
Red Hat Enterprise Linux 9: Signal Handler Race Condition
A race condition vulnerability was discovered in how signals are handled by OpenSSH's server (sshd). If a remote attacker does not authenticate within a set time period, then sshd's SIGALRM handler is called asynchronously. However, this signal handler calls v
- 8.1 High severity
Red Hat Enterprise Linux 9: Concurrent Execution using Shared Resource with Improper Synchronization
A security regression (CVE-2006-5051) was discovered in OpenSSH's server (sshd). There is a race condition which can lead sshd to handle some signals in an unsafe manner. An unauthenticated, remote attacker may be able to trigger it by failing to authenticate