Uncontrolled Recursion

Description

This vulnerability occurs when an application fails to limit how deeply a function can call itself. Without proper controls, this uncontrolled recursion can exhaust system resources like memory or stack space, leading to crashes or denial-of-service.

Extended Description

Uncontrolled recursion happens when a recursive function lacks a proper termination condition or depth limit. This allows it to run indefinitely or until it consumes all available stack memory, causing a stack overflow. Common triggers include processing deeply nested user input (like XML/JSON), complex graph traversals, or mathematical sequences without safety checks. Developers should always implement a maximum recursion depth or convert recursive logic to iterative loops for critical operations. Detecting these flaws manually in a large codebase is challenging, as recursion paths can be complex. While SAST tools can identify the risky pattern, Plexicus uses AI to not only flag the issue but also generate specific, safe code fixes—such as adding depth counters or suggesting iterative alternatives—saving significant manual review and remediation time.

Common Consequences 2

Scope: Availability

Impact: DoS: Resource Consumption (CPU)DoS: Resource Consumption (Memory)

Resources including CPU, memory, and stack memory could be rapidly consumed or exhausted, eventually leading to an exit or crash.

Scope: Confidentiality

Impact: Read Application Data

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.

Detection Methods 1

Automated Static AnalysisHigh

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.)

Potential Mitigations 2

Phase: Implementation

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.

Effectiveness: Moderate

Phase: Implementation

Increase the stack size.

Effectiveness: Limited

Demonstrative Examples 1

ID : DX-204

In this example a mistake exists in the code where the exit condition contained in flg is never called. This results in the function calling itself over and over again until the stack is exhausted.

Code Example:

Bad

void do_something_recursive (int flg) {

Note that the only difference between the Good and Bad examples is that the recursion flag will change value and cause the recursive call to return.

Code Example:

Good

void do_something_recursive (int flg) {

Observed Examples 5

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.

References 1

Automated Source Code Reliability Measure (ASCRM)

Object Management Group (OMG)

01-2016

http://www.omg.org/spec/ASCRM/1.0/

ID: REF-961

Applicable Platforms

Languages:

Not Language-Specific : Undetermined

Modes of Introduction

Implementation

Related Attack Patterns

Alternate Terms

Stack Exhaustion

Affected Resources

Related Weaknesses

ChildOf:

Excessive Iteration (CWE-834)

Taxonomy Mapping

OWASP Top Ten 2004
Software Fault Patterns
OMG ASCRM