As noted in undefined behavior 169 of Annex J of [ISO/IEC 9899-1999], the behavior a program is undefined when
the pointer argument to the
free
orrealloc
function does not match a pointer earlier returned bycalloc
,malloc
, orrealloc
, or the space has been deallocated by a call tofree
orrealloc
.
Freeing memory multiple times has similar consequences to accessing memory after it is freed. (See guideline MEM30-C. Do not access freed memory.) First, reading a pointer to deallocated memory is undefined because the pointer value is indeterminate and may have a trap representation . In the latter case, doing so may cause a hardware trap. When reading a freed pointer doesn't cause a trap, 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. One example of this is VU#623332, which describes a double-free vulnerability in the MIT Kerberos 5 function krb5_recvauth().
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 guideline MEM04-C. Do not perform zero length allocations.)
Noncompliant Code Example
In this noncompliant code 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.
int f(size_t n) { int error_condition = 0; int *x = (int*)malloc(n * sizeof(int)); if (x == NULL) return -1; /* Use x and set error_condition on error. */ if (error_condition == 1) { /* Handle error condition*/ free(x); } /* ... */ free(x); return error_condition; }
Compliant Solution
In this compliant solution, the free a referenced by x
is only freed once. This is accomplished by eliminating the call to free()
when error_condition
is set.
int f(size_t n) { int error_condition = 0; if (n > SIZE_MAX / sizeof(int)) { errno = EOVERFLOW; return -1; } int *x = (int*)malloc(n * sizeof(int)); if (x == NULL) { /* Report allocation failure to caller. */ return -1; } /* Use x and set error_condition on error. */ if (error_condition != 0) { /* Handle error condition and proceed. */ } free(x); return error_condition; }
Note that this solution checks for numeric overflow. (See guideline INT32-C. Ensure that operations on signed integers do not result in overflow.)
Risk Assessment
Freeing 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 |
high |
probable |
medium |
P12 |
L1 |
Automated Detection
Tool |
Version |
Checker |
Description |
---|---|---|---|
9.7.1 |
|
|
|
Fortify SCA |
V. 5.0 |
Double Free |
|
Splint |
3.1.1 |
|
|
2017.07 | RESOURCE_LEAK |
finds resource leaks from variables that go out of scope while owning a resource |
|
2017.07 | USE_AFTER_FREE |
can find the instances where a freed memory is freed again. Coverity Prevent cannot discover all violations of this rule so further verification is necessary |
|
Compass/ROSE |
|
|
can detect some violations of this rule. In particular, false positives may be raised if a variable is freed by a different function than the one that allocated it. Also, it is unable to warn on cases where a call to |
2024.3 | MLK |
|
Related Vulnerabilities
Search for vulnerabilities resulting from the violation of this rule on the CERT website.
Related Guidelines
C++ Secure Coding Standard: MEM31-CPP. Free dynamically allocated memory exactly once
Bibliography
[ISO/IEC PDTR 24772] "XYK Dangling Reference to Heap" and "XYL Memory Leak"
[MIT 2005]
[MITRE 2007] CWE ID 415, "Double Free"
[OWASP, Double Free]
[Viega 2005] "Doubly freeing memory"
[VU#623332]
08. Memory Management (MEM) MEM32-C. Detect and handle memory allocation errors