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 could 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.

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.

x = malloc (number * sizeof(int));
if (x == NULL) {
  /* Handle Allocation Error */
}
/* ... */
if (error_conditon == 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.

x = malloc (number * sizeof(int));
if (x == NULL) {
  /* Handle Allocation Error */
}
/* ... */
if (error_conditon == 1) {
  /* Handle Error Condition*/
}
/* ... */
free(x);

Risk Assessment

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

References

• VU#623332 http://www.kb.cert.org/vuls/id/623332
• MIT krb5 Security Advisory 2005-003 http://web.mit.edu/kerberos/www/advisories/MITKRB5-SA-2005-003-recvauth.txt
• OWASP, Double Free http://www.owasp.org/index.php/Double_Free
• Viega 05 Doubly freeing memory