logo

Improperly Controlled Sequential Memory Allocation

Incomplete Base
Structure: Simple
Description

This vulnerability occurs when a system allocates memory separately for each item in a collection but fails to enforce a global limit on the total memory used by all items combined.

Extended Description

While a developer might cap the memory for a single allocation—like setting a maximum size for one array—an attacker can bypass this by forcing the system to create many such objects in sequence. Each individual allocation stays within its allowed limit, but the cumulative memory consumption across all objects can exhaust available resources, causing a system slowdown or crash. This is a common oversight in systems that handle dynamic collections, such as connection pools, session managers, or request queues. To prevent it, developers must implement a two-tier check: one for per-object allocation and another for the aggregate memory footprint of the entire collection, ensuring the system can't be tricked into a denial of service through repeated small allocations.
Common Consequences 1
Scope: Availability

Impact: DoS: Resource Consumption (Memory)

Not controlling memory allocation can result in a request for too much system memory, possibly leading to a crash of the application due to out-of-memory conditions, or the consumption of a large amount of memory on the system.
Potential Mitigations 2
Phase: Implementation
Ensure multiple allocations of the same kind of object are properly tracked - possibly across multiple sessions, requests, or messages. Define an appropriate strategy for handling requests that exceed the limit, and consider supporting a configuration option so that the administrator can extend the amount of memory to be used if necessary.
Phase: Operation
Run the program using system-provided resource limits for memory. This might still cause the program to crash or exit, but the impact to the rest of the system will be minimized.
Demonstrative Examples 1
This example contains a small allocation of stack memory. When the program was first constructed, the number of times this memory was allocated was probably inconsequential and presented no problem. Over time, as the number of objects in the database grow, the number of allocations will grow - eventually consuming the available stack, i.e. "stack exhaustion." An attacker who is able to add elements to the database could cause stack exhaustion more rapidly than assumed by the developer.

Code Example:

Bad
C


// Gets the size from the number of objects in a database, which over time can conceivably get very large*
int end_limit = get_nmbr_obj_from_db();
int i;
int *base = NULL;
int *p =base;
for (i = 0; i < end_limit; i++)
{


c


c
Since this uses alloca(), it allocates memory directly on the stack. If end_limit is large enough, then the stack can be entirely consumed.
  
Observed Examples 3
CVE-2020-36049JavaScript-based packet decoder uses concatenation of many small strings, causing out-of-memory (OOM) condition
CVE-2019-20176Product allocates a new buffer on the stack for each file in a directory, allowing stack exhaustion
CVE-2013-1591Chain: an integer overflow (Integer Overflow or Wraparound) in the image size calculation causes an infinite loop (Loop with Unreachable Exit Condition ('Infinite Loop')) which sequentially allocates buffers without limits (Improperly Controlled Sequential Memory Allocation) until the stack is full.
   
  
    
 
 
Applicable Platforms 
 
 
 
 
 
Languages:
 
 
 C : UndeterminedC++ : UndeterminedNot Language-Specific : Undetermined 
  
  
 
 
 
  
 
 
Modes of Introduction 
 
 
 
 
 
  Implementation  
 
 
 
  
Related Attack Patterns 
  
Alternate Terms 
Stack Exhaustion
When a weakness allocates excessive memory on the stack, it is often described as "stack exhaustion," which is a technical impact of the weakness. This technical impact is often encountered as a consequence of Memory Allocation with Excessive Size Value and/or Improperly Controlled Sequential Memory Allocation.
      
 
 
Related Weaknesses 
 
 
 
 
  ChildOf:
 Allocation of Resources Without Limits or Throttling (CWE-770) 
  PeerOf:
 Memory Allocation with Excessive Size Value (CWE-789) 
  CanPrecede:
 NULL Pointer Dereference (CWE-476)