The product allocates memory based on an untrusted, large size value, but it does not ensure that the size is within expected limits, allowing arbitrary amounts of memory to be allocated.

Primary

Resultant

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.

Fuzzing
Fuzz testing (fuzzing) is a powerful technique for generating large numbers of diverse inputs - either randomly or algorithmically - and dynamically invoking the code with those inputs. Even with random inputs, it is often capable of generating unexpected results such as crashes, memory corruption, or resource consumption. Fuzzing effectively produces repeatable test cases that clearly indicate bugs, which helps developers to diagnose the issues.
High

Automated Static Analysis
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.)
High

Automated Dynamic Analysis
Use tools that are integrated during
compilation to insert runtime error-checking mechanisms
related to memory safety errors, such as AddressSanitizer
(ASan) for C/C++ [REF-1518].
Moderate
Crafted inputs are necessary to
reach the code containing the error, such as generated
by fuzzers. Also, these tools may reduce performance,
and they only report the error condition - not the
original mistake that led to the
error.

Implementation
Architecture and Design
Perform adequate input validation against any value that influences the amount of memory that is allocated. 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 your 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.

Consider the following code, which accepts an untrusted size value and allocates a buffer to contain a string of the given size.

unsigned int size = GetUntrustedInt();
/* ignore integer overflow (CWE-190) for this example */

unsigned int totBytes = size * sizeof(char);char *string = (char *)malloc(totBytes);InitializeString(string);

Suppose an attacker provides a size value of:

12345678

This will cause 305,419,896 bytes (over 291 megabytes) to be allocated for the string.

Consider the following code, which accepts an untrusted size value and uses the size as an initial capacity for a HashMap.

unsigned int size = GetUntrustedInt();HashMap list = new HashMap(size);

The HashMap constructor will verify that the initial capacity is not negative, however there is no check in place to verify that sufficient memory is present. If the attacker provides a large enough value, the application will run into an OutOfMemoryError.

This code performs a stack allocation based on a length calculation.

int a = 5, b = 6;
size_t len = a - b;
char buf[len]; // Just blows up the stack

}

Since a and b are declared as signed ints, the "a - b" subtraction gives a negative result (-1). However, since len is declared to be unsigned, len is cast to an extremely large positive number (on 32-bit systems - 4294967295). As a result, the buffer buf[len] declaration uses an extremely large size to allocate on the stack, very likely more than the entire computer's memory space.
Miscalculations usually will not be so obvious. The calculation will either be complicated or the result of an attacker's input to attain the negative value.

This example shows a typical attempt to parse a string with an error resulting from a difference in assumptions between the caller to a function and the function's action.

int proc_msg(char *s, int msg_len)
{

// Note space at the end of the string - assume all strings have preamble with space
int pre_len = sizeof("preamble: ");
char buf[pre_len - msg_len];
... Do processing here if we get this far

}
char *s = "preamble: message\n";
char *sl = strchr(s, ':'); // Number of characters up to ':' (not including space)
int jnklen = sl == NULL ? 0 : sl - s; // If undefined pointer, use zero length
int ret_val = proc_msg ("s", jnklen); // Violate assumption of preamble length, end up with negative value, blow out stack

The buffer length ends up being -1, resulting in a blown out stack. The space character after the colon is included in the function calculation, but not in the caller's calculation. This, unfortunately, is not usually so obvious but exists in an obtuse series of calculations.

The following code obtains an untrusted number that is used as an index into an array of messages.

my $num = GetUntrustedNumber();my @messages = ();
$messages[$num] = "Hello World";

The index is not validated at all (CWE-129), so it might be possible for an attacker to modify an element in @messages that was not intended. If an index is used that is larger than the current size of the array, the Perl interpreter automatically expands the array so that the large index works.
If $num is a large value such as 2147483648 (1<<31), then the assignment to $messages[$num] would attempt to create a very large array, then eventually produce an error message such as:
Out of memory during array extend
This memory exhaustion will cause the Perl program to exit, possibly a denial of service. In addition, the lack of memory could also prevent many other programs from successfully running on the system.

This example shows a typical attempt to parse a string with an error resulting from a difference in assumptions between the caller to a function and the function's action. The buffer length ends up being -1 resulting in a blown out stack. The space character after the colon is included in the function calculation, but not in the caller's calculation. This, unfortunately, is not usually so obvious but exists in an obtuse series of calculations.

int proc_msg(char *s, int msg_len)
{
int pre_len = sizeof("preamble: "); // Note space at the end of the string - assume all strings have preamble with space
char buf[pre_len - msg_len];
... Do processing here and set status
return status;
}

char *s = "preamble: message\n";
char *sl = strchr(s, ':'); // Number of characters up to ':' (not including space)
int jnklen = sl == NULL ? 0 : sl - s; // If undefined pointer, use zero length
int ret_val = proc_msg ("s", jnklen); // Violate assumption of preamble length, end up with negative value, blow out stack

int proc_msg(char *s, int msg_len)
{
int pre_len = sizeof("preamble: "); // Note space at the end of the string - assume all strings have preamble with space
if (pre_len <= msg_len) { // Log error; return error_code; }
char buf[pre_len - msg_len];
... Do processing here and set status
return status;
}

char *s = "preamble: message\n";
char *sl = strchr(s, ':'); // Number of characters up to ':' (not including space)
int jnklen = sl == NULL ? 0 : sl - s; // If undefined pointer, use zero length
int ret_val = proc_msg ("s", jnklen); // Violate assumption of preamble length, end up with negative value, blow out stack

CVE-2019-19911
Chain: Python library does not limit the resources used to process images that specify a very large number of bands (CWE-1284), leading to excessive memory consumption (CWE-789) or an integer overflow (CWE-190).
https://www.cve.org/CVERecord?id=CVE-2019-19911

CVE-2010-3701
program uses ::alloca() for encoding messages, but large messages trigger segfault
https://www.cve.org/CVERecord?id=CVE-2010-3701

CVE-2008-1708
memory consumption and daemon exit by specifying a large value in a length field
https://www.cve.org/CVERecord?id=CVE-2008-1708

CVE-2008-0977
large value in a length field leads to memory consumption and crash when no more memory is available
https://www.cve.org/CVERecord?id=CVE-2008-0977

CVE-2006-3791
large key size in game program triggers crash when a resizing function cannot allocate enough memory
https://www.cve.org/CVERecord?id=CVE-2006-3791

CVE-2004-2589
large Content-Length HTTP header value triggers application crash in instant messaging application due to failure in memory allocation
https://www.cve.org/CVERecord?id=CVE-2004-2589

Memory Management

Memory

35
SOAP Array Abuse

MEM35-C
Allocate sufficient memory for an object
Imprecise

IDS32-PL
Validate any integer that is used as an array index
Imprecise

ASCSM-CWE-789

Allowed
This CWE entry is at the Variant 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.

This weakness can be closely associated with integer overflows (CWE-190). Integer overflow attacks would concentrate on providing an extremely large number that triggers an overflow that causes less memory to be allocated than expected. By providing a large value that does not trigger an integer overflow, the attacker could still cause excessive amounts of memory to be allocated.

Uncontrolled memory allocation is possible in many languages, such as dynamic array allocation in perl or initial size parameters in Collections in Java. However, languages like C and C++ where programmers have the power to more directly control memory management will be more susceptible.

CWE Content Team
MITRE
2009-10-21
1.6
2009-10-29

CWE Content Team
MITRE
2010-02-16
updated Taxonomy_Mappings

CWE Content Team
MITRE
2011-03-29
updated Common_Consequences, Observed_Examples

CWE Content Team
MITRE
2011-06-01
updated Common_Consequences

CWE Content Team
MITRE
2012-05-11
updated References

CWE Content Team
MITRE
2017-11-08
updated Applicable_Platforms, Taxonomy_Mappings

CWE Content Team
MITRE
2019-01-03
updated References, Relationships, Taxonomy_Mappings

CWE Content Team
MITRE
2019-06-20
updated Relationships

CWE Content Team
MITRE
2020-02-24
updated Relationships

CWE Content Team
MITRE
2020-06-25
updated Relationships

CWE Content Team
MITRE
2020-08-20
updated Relationships

CWE Content Team
MITRE
2020-12-10
updated Alternate_Terms, Demonstrative_Examples, Description, Likelihood_of_Exploit, Name, Observed_Examples, Relationships, Time_of_Introduction

CWE Content Team
MITRE
2021-03-15
updated Demonstrative_Examples, Relationships

CWE Content Team
MITRE
2022-10-13
updated Observed_Examples

CWE Content Team
MITRE
2023-04-27
updated Detection_Factors, Relationships

CWE Content Team
MITRE
2023-06-29
updated Mapping_Notes, Relationships

CWE Content Team
MITRE
2025-09-09
4.18
2025-09-09
updated Affected_Resources, Functional_Areas, Observed_Examples

CWE Content Team
MITRE
2025-12-11
4.19
2025-12-11
updated Detection_Factors, References

Uncontrolled Memory Allocation