Page History

As noted in [undefined behavior 169|CC. Undefined Behavior#ub_169] of Annex J of \[[ISO/IEC 9899-1999|AA. References#ISO/IEC 9899-1999]\], the behavior a program is [undefined |BB. Definitions#undefined behavior] when

the pointer argument to the free or realloc function does not match a pointer earlier returned by calloc, malloc, or realloc, or the space has been deallocated by a call to free or realloc.

Freeing memory multiple times has similar consequences to accessing memory after it is freed (see 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. 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-C. Do not perform zero length allocations)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 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.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:

#include <stdlib.h>
 
enum { BUFFER_SIZE
size_t num_elem = /* some initial value */;
int error_condition = 0;

int *x32 };

int f(void) {
  char *text_buffer = (intchar *)malloc(num_elem * sizeof(int)BUFFER_SIZE); 
  if (xtext_buffer == NULL) {
    return -1;
  }
  return 0;
}

Compliant Solution

In this compliant solution, the pointer is deallocated with a call to free():

#include <stdlib.h>

enum { BUFFER_SIZE = 32 };

int f(void /* handle allocation error */
}
/* ... */
if (error_condition == 1) {
  /char *text_buffer handle= error(char condition*/
  free(x);
  x = NULL;
}
/* ... */
free(x);
x = NULL;

Compliant Solution

*)malloc(BUFFER_SIZE); 
  if (text_buffer == NULL) {
    return -1;
  }
 
  free(text_buffer);
  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: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 equal to 1.

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

if (num_elem > SIZE_MAX/sizeof(int)#include <stdlib.h>
 
enum { BUFFER_SIZE = 32 };

int f(void) {
  static char *text_buffer = NULL;
  if (text_buffer == NULL) {
   /* 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.

Automated Detection

The LDRA tool suite Version 7.6.0 can detect violations of this rule.

Fortify SCA Version 5.0 can detect violations of this rule with the Double Free checker.

Splint Version 3.1.1 can detect violations of this rule.

...

...

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.

Other Languages

This rule appears in the C++ Secure Coding Standard as MEM31-CPP. Free dynamically allocated memory exactly once.

References

\[[ISO/IEC PDTR 24772|AA. References#ISO/IEC PDTR 24772]\] "XYK Dangling Reference to Heap" and "XYL Memory Leak"
\[[MIT 05|AA. References#MIT 05]\]
\[[MITRE 07|AA. References#MITRE 07]\] [CWE ID 415|http://cwe.mitre.org/data/definitions/415.html], "Double Free"
\[[OWASP, Double Free|AA. References#OWASP Double Free]\]
\[[Viega 05|AA. References#Viega 05]\] "Doubly freeing memory"
\[[VU#623332|AA. References#VU623332]\]

Related Guidelines

Key here (explains table format and definitions)

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

...

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