Before the lifetime of the last pointer that stores the return value of a call to a standard memory allocation function has ended, it must be matched by a call to free()
with that pointer value.
Noncompliant Code Example
In this noncompliant example, the object allocated by the call to malloc()
is not freed before the end of the lifetime of the last pointer text_buffer
referring to the object:
Code Block | ||||
---|---|---|---|---|
| ||||
#include <stdlib.h>
enum { BUFFER_SIZE = 32 };
int f(void) {
char *text_buffer = (char *)malloc(BUFFER_SIZE);
if (text_buffer |
Freeing memory multiple times has similar consequences to accessing memory after it is freed. The underlying data structures that manage the heap can become corrupted in a way that can introduce security vulnerabilities into a program. These types of issues are referred to as double-free vulnerabilities. In practice, double-free vulnerabilities can be exploited to execute arbitrary code. VU#623332, which describes a double-free vulnerability in the MIT Kerberos 5 function krb5_recvauth(), is one example.
To eliminate double-free vulnerabilities, it is necessary to guarantee that dynamic memory is freed exactly one time. Programmers should be wary when freeing memory in a loop or conditional statement; if coded incorrectly, these constructs can lead to double-free vulnerabilities. It is also a common error to misuse the realloc()
function in a manner that results in double-free vulnerabilities (see MEM04-A. Do not perform zero length allocations).
Non-Compliant Code Example
In this example, the memory referred to by x
may be freed twice: once if error_condition
is true and again at the end of the code.
Code Block | ||
---|---|---|
| ||
size_t num_elem = /* some initial value */; int error_condition = 0; int *x = (int *)malloc(num_elem * sizeof(int)); if (x == NULL) { /* Handle Allocation Error */ } /* ... */ if (error_condition == 1return -1; } return 0; } |
Compliant Solution
In this compliant solution, the pointer is deallocated with a call to free()
:
Code Block | ||||
---|---|---|---|---|
| ||||
#include <stdlib.h> enum { BUFFER_SIZE = 32 }; int f(void) { char *text_buffer = (char *)malloc(BUFFER_SIZE); if (text_buffer == NULL) { /* Handle Error Condition*/ return -1; } free(xtext_buffer); } /* ... */ free(x); |
Compliant Solution
return 0;
}
|
Exceptions
MEM31-C-EX1: Allocated memory does not need to be freed if it is assigned to a pointer whose lifetime includes program termination. The following code example illustrates a pointer that stores the return value from malloc()
in a static
variable:Only free a pointer to dynamic memory referred to by x
once. This is accomplished by removing the call to free()
in the section of code executed when error_condition
is true.
Code Block | ||||
---|---|---|---|---|
| ||||
#include <stdlib.h> enum { BUFFER_SIZE = 32 }; int f(void) { static char *text_buffer = NULL; if (text_buffer == NULL) size_t num_elem = /* some initial value */; int error_condition = 0; if (num_elem > SIZE_MAX/sizeof(int)) { /* handle overflow */ } int *x text_buffer = (intchar *)malloc(num_elem * sizeof(int)BUFFER_SIZE); if (xtext_buffer == NULL) { /* Handle Allocation Error */ } /* ... */ if (error_condition == 1) { /* Handle Error Condition*/ } /* ... */ free(x); x = NULL; |
Note that this solution checks for numeric overflow (see INT32-C. Ensure that operations on signed integers do not result in overflow).
Risk Assessment
return -1;
}
}
return 0;
}
|
Risk Assessment
Failing to free memory can result in the exhaustion of system memory resources, which can lead to a denial-of-service attackFreeing memory multiple times can result in an attacker executing arbitrary code with the permissions of the vulnerable process.
Rule | Severity | Likelihood | Remediation Cost | Priority | Level |
---|---|---|---|---|---|
MEM31-C |
Medium |
Probable |
Medium |
P8 |
L2 |
Automated Detection
...
The LDRA tool suite V 7.6.0 can detect violations of this rule.
The Fortify Source Code Analysis Suite Double Free detects instances of memory being freed more than once.
Splint Version 3.1.1 can detect violations of this rule.
...
Tool | Version | Checker | Description | ||||||
---|---|---|---|---|---|---|---|---|---|
Astrée |
| Supported, but no explicit checker | |||||||
Axivion Bauhaus Suite |
| CertC-MEM31 | Can detect dynamically allocated resources that are not freed | ||||||
CodeSonar |
| ALLOC.LEAK | Leak | ||||||
Compass/ROSE | |||||||||
| RESOURCE_LEAK ALLOC_FREE_MISMATCH | Finds resource leaks from variables that go out of scope while owning a resource |
...
Cppcheck |
| memleak leakReturnValNotUsed leakUnsafeArgAlloc memleakOnRealloc | Doesn't use return value of memory allocation function | ||||||
Cppcheck Premium |
| memleak leakReturnValNotUsed leakUnsafeArgAlloc memleakOnRealloc | Doesn't use return value of memory allocation function | ||||||
Helix QAC |
| DF2706, DF2707, DF2708 C++3337, C++3338 | |||||||
Klocwork |
| CL.FFM.ASSIGN CL.FFM.COPY CL.SHALLOW.ASSIGN CL.SHALLOW.COPY FMM.MIGHT FMM.MUST | |||||||
LDRA tool suite |
| 50 D | Partially implemented | ||||||
Parasoft C/C++test |
| CERT_C-MEM31-a | Ensure resources are freed | ||||||
Parasoft Insure++ | Runtime analysis | ||||||||
PC-lint Plus |
| 429 | Fully supported | ||||||
Polyspace Bug Finder |
| CERT C: Rule MEM31-C | Checks for memory leak (rule fully covered) | ||||||
PVS-Studio |
| V773 | |||||||
SonarQube C/C++ Plugin |
| S3584 | |||||||
Splint |
| ||||||||
TrustInSoft Analyzer |
| malloc | Exhaustively verified. |
Related Vulnerabilities
Search for vulnerabilities resulting from the violation of this rule on the CERT website.
References
Wiki Markup |
---|
\[[ISO/IEC PDTR 24772|AA. C References#ISO/IEC PDTR 24772]\] "XYK Dangling Reference to Heap" and "XYL Memory Leak"
\[[MIT 05|AA. C References#MIT 05]\]
\[[MITRE 07|AA. C References#MITRE 07]\] [CWE ID 415|http://cwe.mitre.org/data/definitions/415.html], "Double Free"
\[[OWASP, Double Free|AA. C References#OWASP Double Free]\]
\[[Viega 05|AA. C References#Viega 05]\] "Doubly freeing memory"
\[[VU#623332|AA. C References#VU623332]\] |
Related Guidelines
Key here (explains table format and definitions)
Taxonomy | Taxonomy item | Relationship |
---|---|---|
ISO/IEC TR 24772:2013 | Memory Leak [XYL] | Prior to 2018-01-12: CERT: Unspecified Relationship |
ISO/IEC TS 17961 | Failing to close files or free dynamic memory when they are no longer needed [fileclose] | Prior to 2018-01-12: CERT: Unspecified Relationship |
CWE 2.11 | CWE-401, Improper Release of Memory Before Removing Last Reference ("Memory Leak") | 2017-07-05: CERT: Exact |
CWE 2.11 | CWE-404 | 2017-07-06: CERT: Rule subset of CWE |
CWE 2.11 | CWE-459 | 2017-07-06: CERT: Rule subset of CWE |
CWE 2.11 | CWE-771 | 2017-07-06: CERT: Rule subset of CWE |
CWE 2.11 | CWE-772 | 2017-07-06: CERT: Rule subset of CWE |
CERT-CWE Mapping Notes
Key here for mapping notes
CWE-404/CWE-459/CWE-771/CWE-772 and FIO42-C/MEM31-C
Intersection( FIO42-C, MEM31-C) = Ø
CWE-404 = CWE-459 = CWE-771 = CWE-772
CWE-404 = Union( FIO42-C, MEM31-C list) where list =
- Failure to free resources besides files or memory chunks, such as mutexes)
Bibliography
[ISO/IEC 9899:2024] | Subclause 7.24.3, "Memory Management Functions" |
...
08. Memory Management (MEM) MEM32-C. Detect and handle memory allocation errors