Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

Before the lifetime of the last pointer object that stores the return value of a call to a standard memory allocation function has ended, it must be matched by a call to a standard memory deallocation function with that pointer value.

Noncompliant Code Example

In this noncompliant example, the object allocated by the call to malloc() is not freed before the end of the lifetime of last pointer object (text_buffer) referring to the object.

As noted under undefined behavior 179 in Annex J of the C Standard [ISO/IEC 9899:2011], the behavior of a program is undefined when

the pointer argument to the free or realloc function does not match a pointer earlier returned by a memory management function, 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 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 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 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:

Code Block
bgColor#FFCCCC
langc
#include <stdlib.h>
 
int f(size_t nvoid) {
  intchar error_condition = 0;

  int *x*text_buffer = (intchar *)malloc(n * sizeof(int));BUFSIZ); 
  if (xtext_buffer == NULL) {
    return -1;

  /* Use x and set error_condition on error */

  if (error_condition == 1) {
    /* Handle error */
    free(x);
  }

  free(x);
  return error_condition0;
}

Compliant

...

Solution 

In this compliant solution, the memory referenced by x is freed only once. This is accomplished by eliminating the call to free() when error_condition is set:pointer object that stores the return value from malloc() is stored in a variable of static storage duration.

Code Block
bgColor#ccccff
langc
#include <stdlib.h>
 
int f(size_t n) {
  int error_condition = 0;

  if (n > SIZE_MAX / sizeof(int)) {
    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);

  x = 0;
  return error_condition;
}

Note that this solution checks for numeric overflow (see INT32-C. Ensure that operations on signed integers do not result in overflow). It also complies with MEM01-C. Store a new value in pointers immediately after free().

Noncompliant Code Example (realloc())

The memory referenced by p may be freed twice in this noncompliant code example:

Code Block
bgColor#FFCCCC
langc
#include <stdlib.h>
 
/* p is a pointer to dynamically allocated memory */
void func(void *p, size_t size) {
  p2 = realloc(p, size);
  if (p2char *text_buffer;
 
int f(void) {
  text_buffer = (char *)malloc(BUFSIZ); 
  if (text_buffer == NULL) {
    /* p may be indeterminate when (size == 0) */ 
    free(p); 
    return;
  }
}

Subclause 7.22.3 of the C Standard [ISO/IEC 9899:2011] states:

...

-

...

And subclause 7.22.3.5 states:

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

If realloc() is called with size equal to 0 and then a null pointer is returned, the old value should be unchanged. However, there are some common but nonconforming implementations that free the pointer, including the following:

...

1

...

In nonconforming implementations, calling free on the original pointer might result in a double-free vulnerability. However, not calling free on the original pointer might result in a memory leak.

Compliant Solution (realloc())

In this compliant solution, allocations of 0 bytes are prevented, ensuring that p is freed exactly once:

Code Block
bgColor#ccccff
langc
#include <stdlib.h>
 
/* p is a pointer to dynamically allocated memory */
void func(void *p, size_t size) {
  if (size) {
    p2 = realloc(p, size);
    if (p2 == NULL) {
      free(p);
      return;
    }
  } else {
    free(p);
    return;
  }
};
  }
  return 0;
}

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

Compass/ROSE

Coverity

Include Page
Coverity_V
Coverity_V

RESOURCE_LEAK

USE_AFTER_FREE

Finds resource leaks from variables that go out of scope while owning a resourceCan find the instances where a freed memory is freed again. Coverity Prevent cannot discover all violations of this rule, so further verification is necessary

Fortify SCA

5.0

Double Free

 

Klocwork

Include Page
Klocwork_V
Klocwork_V

MLK
UFM.FFM

 

LDRA tool suite

Include Page
LDRA_V
LDRA_V

484 S

Fully implemented

Splint

Include Page
Splint_V
Splint_V
  

Related Vulnerabilities

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

Related Guidelines

C Coding StandardMEM01-. Store a new value in pointers immediately after free()
MEM04-C. Do not perform zero-length allocations
INT32-C. Ensure that operations on signed integers do not result in overflow
CERT CCERT C++ Secure Coding StandardMEM31-CPP. Free dynamically allocated memory exactly once
ISO/IEC TR 24772:2013Dangling Reference to Heap [XYK]
Memory Leak [XYL]
ISO/IEC TS 17961Freeing memory multiple times [dblfreeFailing to close files or free dynamic memory when they are no longer needed [fileclose]
MITRE CWECWE-415, Double free

Bibliography

 
[ISO/IEC 9899:2011]Subclause 7.22.3, "Memory Management Functions"
Annex J, J.2, "Undefined Behavior"
[MIT 2005] 
[OWASP Double Free]"Double Free"
[Viega 2005]"Doubly Freeing Memory"
[VU#623332]

 

...