The product manages a group of objects or resources and performs a separate memory allocation for each object, but it does not properly limit the total amount of memory that is consumed by all of the combined objects.

While the product might limit the amount of memory that is allocated in a single operation for a single object (such as a malloc of an array), if an attacker can cause multiple objects to be allocated in separate operations, then this might cause higher total memory consumption than the developer intended, leading to a denial of service.

Primary

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 CWE-789 and/or CWE-1325.

Implementation

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

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.

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.

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.

// 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++)
{

*p = alloca(sizeof(int *)); // Allocate memory on the stack
p = *p; // // Point to the next location to be saved

}

Since this uses alloca(), it allocates memory directly on the stack. If end_limit is large enough, then the stack can be entirely consumed.

CVE-2020-36049
JavaScript-based packet decoder uses concatenation of many small strings, causing out-of-memory (OOM) condition
https://www.cve.org/CVERecord?id=CVE-2020-36049

CVE-2019-20176
Product allocates a new buffer on the stack for each file in a directory, allowing stack exhaustion
https://www.cve.org/CVERecord?id=CVE-2019-20176

CVE-2013-1591
Chain: an integer overflow (CWE-190) in the image size calculation causes an infinite loop (CWE-835) which sequentially allocates buffers without limits (CWE-1325) until the stack is full.
https://www.cve.org/CVERecord?id=CVE-2013-1591

Allowed
This CWE entry is at the Base level of abstraction, which is a preferred level of abstraction for mapping to the root causes of vulnerabilities.
Carefully read both the name and description to ensure that this mapping is an appropriate fit. Do not try to 'force' a mapping to a lower-level Base/Variant simply to comply with this preferred level of abstraction.

CWE Content Team
MITRE
2020-12-07
4.3
2020-12-10

CWE Content Team
MITRE
2021-07-20
updated Observed_Examples

CWE Content Team
MITRE
2023-04-27
updated Relationships

CWE Content Team
MITRE
2023-06-29
updated Mapping_Notes