CWE-834: Excessive Iteration

Description:
The product performs an iteration or loop without sufficiently limiting the number of times that the loop is executed.

Extended Description:
If the iteration can be influenced by an attacker, this weakness could allow attackers to consume excessive resources such as CPU or memory. In many cases, a loop does not need to be infinite in order to cause enough resource consumption to adversely affect the product or its host system; it depends on the amount of resources consumed per iteration.

Affected languages: Not Language-Specific
Affected technologies: Not Technology-Specific
Parent weaknesses: CWE-691

Consequences:
  - Availability: DoS: Resource Consumption (CPU)

Detection methods:
  - Dynamic Analysis with Manual Results Interpretation: According to SOAR [REF-1479], the following detection techniques may be useful: 
                   
                      Cost effective for partial coverage: 
                         
             
  - Manual Static Analysis - Source Code: According to SOAR [REF-1479], the following detection techniques may be useful: 
                   
                      Cost effective for partial coverage: 
                         
             
  - Automated Static Analysis - Source Code: According to SOAR [REF-1479], the following detection techniques may be useful: 
                   
                      Highly cost effective: 
                         
                           
  - Architecture or Design Review: According to SOAR [REF-1479], the following detection techniques may be useful: 
                   
                      Highly cost effective: 
                         
                           

Demonstrative examples:
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.
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.
void do_something_recursive (int flg) 
	       { 
	        
		 ... // Do some real work here, but the value of flg is unmodified 
		 if (flg) { do_something_recursive (flg); }    // flg is never modified so it is always TRUE - this call will continue until the stack explodes 
	        
	       } 
	       int flag = 1; // Set to TRUE 
	       do_something_recursive (flag);
void do_something_recursive (int flg) 
	       { 
	        
		 ... // Do some 

For this example, the method isReorderNeeded is part of a bookstore application that determines if a particular book needs to be reordered based on the current inventory count and the rate at which the book is being sold.
However, the while loop will become an infinite loop if the rateSold input parameter has a value of zero since the inventoryCount will never fall below the minimumCount. In this case the input parameter should be validated to ensure that a value of zero does not cause an infinite loop, as in the following code.
public boolean isReorderNeeded(String bookISBN, int rateSold) { 
                
                  boolean isReorder = false; 
                  int minimumCount = 10; int days = 0; 
                  
                  // get inventory count for book 
           

Real-world examples:
  - CVE-2011-1027: Chain: off-by-one error (CWE-193) leads to infinite loop (CWE-835) using invalid hex-encoded characters.
  - CVE-2006-6499: Chain: web browser crashes due to infinite loop - "bad
	      looping logic [that relies on] floating point math [CWE-1339] to exit
	      the loop [CWE-835]"