この製品は、競合状態を引き起こすシグナル・ハンドラを使用している。
シグナル・ハンドラは非同期アクションをサポートするため、レース状態はシグナル・ハンドラで頻繁に発生する。このようなレースコンディションには、様々な根本原因や症状があります。攻撃者は、シグナルハンドラのレースコンディションを悪用して、製品の状態を破壊し、サービス拒否やコード実行につながる可能性があります。
これらの問題は、再入可能でない関数や状態に依存する動作がシグナル・ハンドラ内で発生し、それらがいつでも呼び出される可能性がある場合に発生します。これらの動作は、割り込まれた「通常の」コードや、他のシグナル・ハンドラも呼び出される可能性があるため、その仮定に違反する可能性があります。これらの関数がタイミング悪く呼び出された場合（例えば、再入可能でない関数が既に実行されている間など）、メモリ破壊が発生し、コード実行に悪用される可能性があります。シグナル・ハンドラ内でfreeが呼び出されると、二重のfreeが発生し、write-what-where状態になる。あるポインタが解放された後にNULLに設定されたとしても、メモリが解放された時点とポインタがNULLに設定された時点の間に競合状態が存在します。これは、同じシグナル・ハンドラが複数のシグナルに設定されている場合に特に問題となる。
シグナル・ハンドラに関連する既知の動作の中には、「シグナル・ハンドラの競合状態」と呼ばれるものがいくつかある：
シグナルハンドラの脆弱性は、特定の保護メカニズムがないことに基づいて分類されることが多いが、CWEではこのような分類は推奨されていない。このような保護メカニズムは、共有リソースへのアクセスの排他性や、関連するコードの動作の原子性を保持することがあります：
The product uses a signal handler that introduces a race condition.
Race conditions frequently occur in signal handlers, since signal handlers support asynchronous actions. These race conditions have a variety of root causes and symptoms. Attackers may be able to exploit a signal handler race condition to cause the product state to be corrupted, possibly leading to a denial of service or even code execution.
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":
Signal handler vulnerabilities are often classified based on the absence of a specific protection mechanism, although this style of classification is discouraged in CWE because programmers often have a choice of several different mechanisms for addressing the weakness. Such protection mechanisms may preserve exclusivity of access to the shared resource, and behavioral atomicity for the relevant code: