CWE-1325 covers products that allocate memory separately for each object in a group but never limit the combined total. It is a denial of service weakness found in C, C++ and other languages.
How it happens
A developer may cap the size of one allocation, such as a single array. If an attacker can cause many objects to be allocated in separate operations, total memory use can go far beyond what was intended. The product can then run out of memory.
The record lists three observed CVEs that show different shapes of the problem:
- CVE-2020-36049: a JavaScript packet decoder concatenates many small strings, causing an out-of-memory condition.
- CVE-2019-20176: a product allocates a new stack buffer for each file in a directory, allowing stack exhaustion.
- CVE-2013-1591: a chain where an integer overflow in an image size calculation causes an infinite loop that allocates buffers without limit until the stack is full.
A simple C illustration:
/* Vulnerable: each record is small, but the count is attacker controlled */
for (uint32_t i = 0; i < hdr.count; i++) {
items[i] = malloc(256);
}
/* Safer: enforce a total budget across the whole message */
#define MAX_ITEMS 1024
if (hdr.count > MAX_ITEMS) {
return ERR_TOO_MANY;
}
What an attacker gains
Availability. MITRE describes a request for too much system memory, leading to a crash from out-of-memory conditions or heavy memory use across the system.
How to find it
The record lists no detection methods. Review every loop or parser where the number of allocations depends on input, and check that a total budget exists per request, session or message. Fuzzing with large counts is a quick test.
How to fix it
- Track multiple allocations of the same kind of object, possibly across sessions, requests or messages.
- Define what happens when a request exceeds the limit, and consider a configuration option so an administrator can raise the limit if needed.
- At run time, use system-provided resource limits for memory. The program may still crash, but the impact on the rest of the system is smaller.
Quick check
Why is a per-allocation size limit not enough?
An attacker can trigger many separate small allocations whose total exceeds what the developer intended.
