Page History

As noted in undefined behavior 169179 of Annex J of the C standard [ISO/IEC 9899-1999:2011], the behavior a program is undefined when

...

Freeing memory multiple times has similar consequences to accessing memory after it is freed. (See rule MEM30-C. Do not access freed memory.) First, reading a pointer to deallocated memory is undefined because the pointer value is indeterminate and can have a trap representation. In the latter case, doing so can 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 called 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 recommendation MEM04-C. Do not perform zero length allocations.)

Noncompliant Code Example

...

(malloc())

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 (

...

malloc())

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.

...

Note that this solution checks for numeric overflow. (See rule INT32-C. Ensure that operations on signed integers do not result in overflow.)

...

/* p is a pointer to dynamically allocated memory */
p2 = realloc(p, size);
if (p2 == NULL) {
  free(p); /* p may be indeterminate when (size == 0) */
  return;
}

According to the C99 C standard [ISO/IEC 9899-1999:2011] (7.2022.3):

If the size of the space requested is zero, the behavior is implementation defined: either a null pointer is returned, or the behavior is as if the size were some nonzero value, except that the returned pointer shall not be used to access an object.

and (7.2022.3.45):

If memory for the new object cannot be allocated, the old object is not deallocated and its value is unchanged.

...

Related Vulnerabilities

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

...

CERT C Secure Coding Standard: MEM04-C. Do not perform zero length allocations

ISO/IEC 9899:2011 Section 7.22.3, "Memory Management Functions"

ISO/IEC TR 17961 (Draft) Freeing memory multiple times [dblfree]

...

[MIT 2005]
[OWASP, Double Free]
[Viega 2005] "Doubly freeing memoryFreeing Memory"
[VU#623332]

...