CWE Rule 1325

Improperly Controlled Sequential Memory Allocation

Since R2026a

Description

Improperly Controlled Sequential Memory Allocation.

Polyspace Implementation

The rule checker checks for Unbound resource allocation in loops.

Examples

Unbound resource allocation in loops

Issue

The issue occurs when your code performs memory allocation in a loop, for example, by using a malloc() and there is no explicit bound on the number of allocations.

For each loop, Polyspace checks that the number of memory allocations is less than or equal to 100. If this upper bound can be exceeded, the checker flags the loop. If there is not enough information to determine the upper bound, the checker also flags the loop, as this implies the loop is not easily readable by humans and is not properly controlled.

Polyspace does not report a violation on memory allocations that:

• Occur within a recursive functions

• Are a single large allocation, such as malloc(1GB)

• Are called within a loop

Additionally, Polyspace does not take into account deallocation for this rule.

Risk

If the total memory consumed by multiple allocations is not limited, available resources such as the stack or heap can be exhausted. This can lead to denial of service. Attackers can exploit this weakness by causing a significant number allocations, consuming all available memory more rapidly than the developer anticipated, causing the application to crash or become unresponsive.

Fix

Explicitly bound the number of allocations performed in the execution of the loop. For example, use the loop condition i < (end_limit < 100 ? end_limit : 100) or check the allocation limit before entering the allocation loop. By enforcing an upper bound, you prevent excessive memory consumption and reduce the risk of stack or heap exhaustion.

Example

In this example, the number of allocations is determined by end_limit, which is obtained from an external source such as a database. If end_limit is large, the loop allocates a large amount of stack memory, potentially exhausting the stack and causing the program to crash. There is no explicit upper bound on the total number of allocations, making this code vulnerable to resource exhaustion.

#include <alloca.h>
#include <stdlib.h>
extern int get_nmbr_obj_from_db();
#define NULL 0

typedef struct _chainedList {
    int data;
    struct _chainedList* next;
} chainedList;

int main (){
    int end_limit = get_nmbr_obj_from_db();
    int i;
    chainedList* base = NULL;
    chainedList* p = base;

    for (i = 0; i < end_limit; i++) {
        p = (chainedList*)alloca(sizeof(chainedList));   //Noncompliant
        p = p->next;
    }
    return 0;
}

Correction

In this example, the number of allocations in the loop is explicitly bounded to a maximum of 100. This prevents the loop from allocating excessive stack memory, even if end_limit is very large. By introducing an upper limit, the risk of stack exhaustion is mitigated, and the code becomes compliant with the rule.

#include <alloca.h>
#include <stdlib.h>
extern int get_nmbr_obj_from_db();
#define NULL 0

typedef struct _chainedList {
    int data;
    struct _chainedList* next;
} chainedList;

void compliant_examples (){
    int end_limit = get_nmbr_obj_from_db();
    int i;
    chainedList* base = NULL;
    chainedList* p = base;

    for (i = 0; i < (end_limit < 100 ? end_limit : 100); i++) {
        p = (chainedList*)alloca(sizeof(chainedList));       //Compliant
        p = p->next;
    }

    if (end_limit < 100) {
        for (i = 0; i < end_limit ; i++) {
            p = (chainedList*)alloca(sizeof(chainedList));   //Compliant
            p = p->next;
        }
    }
}

Check Information

Category: Others

PQL Name: std.cwe_native.R1325

Version History

Introduced in R2026a