Memory is a limited resource and can be exhausted. Available memory is typically bounded by the sum of the amount of physical memory and the swap space allocated to the operating system by the administrator. For example, a system with 1GB of physical memory configured with 2GB of swap space may be able to allocate, at most, 3GB of heap space total to all running processes (minus the size of the operating system itself and the text and data segments of all running processes). Once all virtual memory has been allocated, requests for more memory will fail. As discussed in MEM32ERR33-C. Detect and handle memory allocation standard library errors, programs that fail to check for and properly handle memory allocation failures will have undefined behavior and are likely to crash when heap space is exhausted. Heap exhaustion can result from
...
This example places no upper bound on the memory space required. As a result, the program can easily exhaust the heap. A heap error will be generated if the heap continues to be populated, even if there is no space available.
Code Block | ||||
---|---|---|---|---|
| ||||
#include <stdio.h> #include <string.h> #include <stdlib.h> enum {MAX_LENGTH=100}; typedef struct namelist_s { char name[MAX_LENGTH]; struct namelist_s* next; } *namelist_t; int main() { namelist_t names = NULL; char new_name[MAX_LENGTH]; do { /* * Adding unknown number of records to a list; * Thethe user can enter as much data as he wants * and exhaust the heap. */ puts("To quit, enter \"quit\""); puts("Enter record:"); fgets(new_name, MAX_LENGTH, stdin); if (strcmp(new_name, "quit") != 0) { /* * Names continue to be added without bothering * about the size on the heap. */ unsigned int i = strlen(new_name) - 1; if (new_name[i] == '\n') new_name[i] = '\0'; namelist_t new_entry = (namelist_t) malloc(sizeof( struct namelist_s)); if (new_entry == NULL) { /* handleHandle error */ } strcpy( new_entry->name, new_name); new_entry->next = names; names = new_entry; } puts(new_name); } while (strcmp( new_name, "quit") != 0); return 0; } |
...
It is difficult to pinpoint violations of this recommendation because static analysis tools are currently unable to identify code that can lead to heap exhaustion. The heap size also varies for different runtime environments.
Rule | Severity | Likelihood | Remediation Cost | Priority | Level |
---|---|---|---|---|---|
MEM11-C |
Low |
Probable |
High | P2 | L3 |
Automated Detection
Tool | Version | Checker | Description | ||||||
---|---|---|---|---|---|---|---|---|---|
CodeSonar |
| ALLOC.LEAK | Leak | ||||||
LDRA tool suite |
| 26 S, 140 S, 6 D, 28 D, 5 C, 1 U | Partially implemented | ||||||
PC-lint Plus |
| 413, 613 | Assistance provided: reports use of null pointers including those which could be returned when a call to an allocation function fails | ||||||
Polyspace Bug Finder |
| Checks for unprotected dynamic memory allocation (rule partially covered) |
Related Vulnerabilities
Search for vulnerabilities resulting from the violation of this rule on the CERT website.
Related Guidelines
SEI CERT C++ |
Coding Standard | VOID MEM12-CPP. Do not assume infinite heap space |
CERT Oracle Secure Coding Standard for Java | MSC05-J. Do not exhaust heap space |
MITRE CWE | CWE-770, Allocation of resources without limits or throttling |
...