MEM31-C. Free dynamically allocated memory exactly once

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.

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 == 1) {
  /* Handle Error Condition*/
  free(x);
}
/* ... */
free(x);

Compliant Solution

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.

size_t num_elem = /* some initial value */;
int error_condition = 0;

if (num_elem > SIZE_MAX/sizeof(int)) {
   /* handle overflow */
}
int *x = (int *)malloc(num_elem * sizeof(int));
if (x == 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

Freeing memory multiple times can result in an attacker executing arbitrary code with the permissions of the vulnerable process.

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.

The Coverity Prevent RESOURCE_LEAK finds resource leaks from variables that go out of scope while owning a resource. 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 free() happens inside of a for-loop.

Related Vulnerabilities

Search for vulnerabilities resulting from the violation of this rule on the CERT website.

References

[[ISO/IEC PDTR 24772]] "XYK Dangling Reference to Heap" and "XYL Memory Leak"
[[MIT 05]]
[[MITRE 07]] CWE ID 415, "Double Free"
[[OWASP, Double Free]]
[[Viega 05]] "Doubly freeing memory"
[[VU#623332]]

      08. Memory Management (MEM)       MEM32-C. Detect and handle memory allocation errors