The product does not properly control the amount of recursion that takes place, consuming excessive resources, such as allocated memory or the program stack.
Ensure an end condition will be reached under all logic conditions. The end condition may include testing against the depth of recursion and exiting with an error if the recursion goes too deep. The complexity of the end condition contributes to the effectiveness of this action.
Increase the stack size.
Resources including CPU, memory, and stack memory could be rapidly consumed or exhausted, eventually leading to an exit or crash.
In some cases, an application's interpreter might kill a process or thread that appears to be consuming too much resources, such as with PHP's memory_limit setting. When the interpreter kills the process/thread, it might report an error containing detailed information such as the application's installation path.
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.)
CVE-2007-1285Deeply nested arrays trigger stack exhaustion.
CVE-2007-3409Self-referencing pointers create infinite loop and resultant stack exhaustion.
CVE-2016-10707Javascript application accidentally changes input in a way that prevents a recursive call from detecting an exit condition.
CVE-2016-3627An attempt to recover a corrupted XML file infinite recursion protection counter was not always incremented missing the exit condition.
CVE-2019-15118USB-audio driver's descriptor code parsing allows unlimited recursion leading to stack exhaustion.