Skip to end of metadata
Go to start of metadata

According to the C Standard, using the value of a pointer that refers to space deallocated by a call to the free() or realloc() function is undefined behavior. (See undefined behavior 177.)

Reading a pointer to deallocated memory is undefined behavior because the pointer value is indeterminate and might be a trap representation. Fetching a trap representation might perform a hardware trap (but is not required to).

It is at the memory manager's discretion when to reallocate or recycle the freed memory. When memory is freed, all pointers into it become invalid, and its contents might either be returned to the operating system, making the freed space inaccessible, or remain intact and accessible. As a result, the data at the freed location can appear to be valid but change unexpectedly. Consequently, memory must not be written to or read from once it is freed.

Noncompliant Code Example

This example from Brian Kernighan and Dennis Ritchie [Kernighan 1988] shows both the incorrect and correct techniques for freeing the memory associated with a linked list. In their (intentionally) incorrect example, p is freed before p->next is executed, so that p->next reads memory that has already been freed.

#include <stdlib.h>
 
struct node {
  int value;
  struct node *next;
};
 
void free_list(struct node *head) {
  for (struct node *p = head; p != NULL; p = p->next) {
    free(p);
  }
}

Compliant Solution

Kernighan and Ritchie correct this error by storing a reference to p->next  in q before freeing p:

#include <stdlib.h>
 
struct node {
  int value;
  struct node *next;
};
 
void free_list(struct node *head) {
  struct node *q;
  for (struct node *p = head; p != NULL; p = q) {
    q = p->next;
    free(p);
  }
}

Noncompliant Code Example

In this noncompliant code example, buf is written to after it has been freed. Write-after-free vulnerabilities can be exploited to run arbitrary code with the permissions of the vulnerable process. Typically, allocations and frees are far removed, making it difficult to recognize and diagnose these problems.

#include <stdlib.h>
#include <string.h>

int main(int argc, char *argv[]) {
  char *return_val = 0;
  const size_t bufsize = strlen(argv[0]) + 1;
  char *buf = (char *)malloc(bufsize);
  if (!buf) {
    return EXIT_FAILURE;
  }
  /* ... */
  free(buf);
  /* ... */
  strcpy(buf, argv[0]);
  /* ... */
  return EXIT_SUCCESS;
}

Compliant Solution

In this compliant solution, the memory is freed after its final use:

#include <stdlib.h>
#include <string.h>

int main(int argc, char *argv[]) {
  char *return_val = 0;
  const size_t bufsize = strlen(argv[0]) + 1;
  char *buf = (char *)malloc(bufsize);
  if (!buf) {
    return EXIT_FAILURE;
  }
  /* ... */
  strcpy(buf, argv[0]);
  /* ... */
  free(buf);
  return EXIT_SUCCESS;
}

Noncompliant Code Example

In this noncompliant example, realloc() may free c_str1 when it returns a null pointer, resulting in c_str1 being freed twice.  The C Standards Committee's proposed response to Defect Report #400 makes it implementation-defined whether or not the old object is deallocated when size is zero and memory for the new object is not allocated. The current implementation of realloc() in the GNU C Library and Microsoft Visual Studio's Runtime Library will free c_str1 and return a null pointer for zero byte allocations.  Freeing a pointer twice can result in a potentially exploitable vulnerability commonly referred to as a double-free vulnerability [Seacord 2013b].

#include <stdlib.h>
 
void f(char *c_str1, size_t size) {
  char *c_str2 = (char *)realloc(c_str1, size);
  if (c_str2 == NULL) {
    free(c_str1);
  }
}

Compliant Solution

This compliant solution does not pass a size argument of zero to the realloc() function, eliminating the possibility of c_str1 being freed twice:

#include <stdlib.h>
 
void f(char *c_str1, size_t size) {
  if (size != 0) {
    char *c_str2 = (char *)realloc(c_str1, size); 
    if (c_str2 == NULL) {
      free(c_str1); 
    }
  }
  else {
    free(c_str1);
  }
 
}

If the intent of calling f() is to reduce the size of the object, then doing nothing when the size is zero would be unexpected; instead, this compliant solution frees the object.

Noncompliant Code Example

In this noncompliant example (CVE-2009-1364) from libwmf version 0.2.8.4, the return value of gdRealloc (a simple wrapper around realloc() that reallocates space pointed to by im->clip->list) is set to more. However, the value of im->clip->list is used directly afterwards in the code, and the C Standard specifies that if realloc() moves the area pointed to, then the original block is freed. An attacker can then execute arbitrary code by forcing a reallocation (with a sufficient im->clip->count) and accessing freed memory [xorl 2009].

void gdClipSetAdd(gdImagePtr im, gdClipRectanglePtr rect) {
  gdClipRectanglePtr more;
  if (im->clip == 0) {
   /* ... */
  }
  if (im->clip->count == im->clip->max) {
    more = gdRealloc (im->clip->list,(im->clip->max + 8) *
                      sizeof (gdClipRectangle));
    /*
     * If the realloc fails, then we have not lost the
     * im->clip->list value.
     */
    if (more == 0) return; 
    im->clip->max += 8;
  }
  im->clip->list[im->clip->count] = *rect;
  im->clip->count++;

}

Compliant Solution

This compliant solution simply reassigns im->clip->list to the value of more after the call to realloc():

void gdClipSetAdd(gdImagePtr im, gdClipRectanglePtr rect) {
  gdClipRectanglePtr more;
  if (im->clip == 0) {
    /* ... */
  }
  if (im->clip->count == im->clip->max) {
    more = gdRealloc (im->clip->list,(im->clip->max + 8) *
                      sizeof (gdClipRectangle));
    if (more == 0) return;
    im->clip->max += 8;
    im->clip->list = more;
  }
  im->clip->list[im->clip->count] = *rect;
  im->clip->count++;

}

Risk Assessment

Reading memory that has already been freed can lead to abnormal program termination and denial-of-service attacks. Writing memory that has already been freed can additionally lead to the execution of arbitrary code with the permissions of the vulnerable process. 

Freeing memory multiple times has similar consequences to accessing memory after it is freed. Reading a pointer to deallocated memory is undefined behavior because the pointer value is indeterminate and might be a trap representation. When reading from or writing to freed memory does not cause a trap, it may corrupt the underlying data structures that manage the heap in a manner that can be exploited to execute arbitrary code. Alternatively, writing to memory after it has been freed might modify memory that has been reallocated.

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. Beware of zero-length allocations.)

Rule

Severity

Likelihood

Remediation Cost

Priority

Level

MEM30-C

High

Likely

Medium

P18

L1

Automated Detection

Tool

Version

Checker

Description

Astrée
18.10

Supported: Astrée reports accesses to freed allocated memory.
Axivion Bauhaus Suite

6.9.0

CertC-MEM30Detects memory accesses after its deallocation and double memory deallocations
CodeSonar
5.0p0

ALLOC.UAF

Use after free
Compass/ROSE




Coverity

2017.07

USE_AFTER_FREE

Can detect the specific instances where memory is deallocated more than once or read/written to the target of a freed pointer

Klocwork
2018

UFM.DEREF.MIGHT
UFM.DEREF.MUST
UFM.FFM.MIGHT
UFM.FFM.MUST

UFM.RETURN.MIGHT
UFM.RETURN.MUST
UFM.USE.MIGHT
UFM.USE.MUST


LDRA tool suite
9.7.1

51 D, 484 S, 112 D

Partially implemented

Parasoft C/C++test
10.4

CERT_C-MEM30-a

Do not use resources that have been freed
Parasoft Insure++

Runtime analysis
Polyspace Bug Finder

R2018a

Deallocation of previously deallocated pointer

Invalid use of standard library string routine

Use of previously freed pointer

MISRA C:2012 Dir 4.13

MISRA C:2012 Rule 18.6

MISRA C:2012 Rule 22.1

MISRA C:2012 Rule 22.2

Memory freed more than once without allocation

Standard library string function called with invalid arguments

Memory accessed after deallocation

Functions which are designed to provide operations on a resource should be called in an appropriate sequence

The address of an object with automatic storage shall not be copied to another object that persists after the first object has ceased to exist

All resources obtained dynamically by means of Standard Library functions shall be explicitly released

A block of memory shall only be freed if it was allocated by means of a Standard Library function

PRQA QA-C9.1 1769, 1770 
PRQA QA-C++4.2 3339, 4303, 4304 
PVS-Studio

6.23

V586, V774
Splint
3.1.1



Related Vulnerabilities

VU#623332 describes a double-free vulnerability in the MIT Kerberos 5 function krb5_recvauth()

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

Related Guidelines

Key here (explains table format and definitions)

Taxonomy

Taxonomy item

Relationship

CERT C Secure Coding StandardMEM01-C. Store a new value in pointers immediately after free()Prior to 2018-01-12: CERT: Unspecified Relationship
CERT CMEM50-CPP. Do not access freed memoryPrior to 2018-01-12: CERT: Unspecified Relationship
ISO/IEC TR 24772:2013Dangling References to Stack Frames [DCM]Prior to 2018-01-12: CERT: Unspecified Relationship
ISO/IEC TR 24772:2013Dangling Reference to Heap [XYK]Prior to 2018-01-12: CERT: Unspecified Relationship
ISO/IEC TS 17961Accessing freed memory [accfree]Prior to 2018-01-12: CERT: Unspecified Relationship
ISO/IEC TS 17961Freeing memory multiple times [dblfree]Prior to 2018-01-12: CERT: Unspecified Relationship
MISRA C:2012Rule 18.6 (required)Prior to 2018-01-12: CERT: Unspecified Relationship
CWE 2.11CWE-416, Use After Free2017-07-07: CERT: Exact
CWE 2.11CWE-6722017-07-07: CERT: Rule subset of CWE

CERT-CWE Mapping Notes

Key here for mapping notes

CWE-672 and MEM30-C

Intersection( MEM30-C, FIO46-C) = Ø CWE-672 = Union( MEM30-C, list) where list =


  • Use of a resource, other than memory after it has been released (eg: reusing a closed file, or expired mutex)


CWE-666 and MEM30-C

Intersection( MEM30-C, FIO46-C) = Ø

CWE-672 = Subset( CWE-666)

CWE-758 and MEM30-C

CWE-758 = Union( MEM30-C, list) where list =


  • Undefined behavior that is not covered by use-after-free errors


CWE-415 and MEM30-C

MEM30-C = Union( CWE-456, list) where list =


  • Dereference of a pointer after freeing it (besides passing it to free() a second time)


Bibliography

[ISO/IEC 9899:2011]7.22.3, "Memory Management Functions"
[Kernighan 1988]Section 7.8.5, "Storage Management"
[OWASP Freed Memory]
[MIT 2005]
[Seacord 2013b]Chapter 4, "Dynamic Memory Management"
[Viega 2005]Section 5.2.19, "Using Freed Memory"
[VU#623332]
[xorl 2009]CVE-2009-1364: LibWMF Pointer Use after free()



6 Comments

  1. It may worth noting that there are other means of "free"ing memory other than free().

    For example, memory allocated with alloca() is freed automatically at the end of the block. And static memory is freed with then module that contains the static definition if unloaded from memory (a big deal with programs that dynamically load/unload shared objects/libraries).

    In all of these cases, referencing (R or W) the deallocated memory is an error,  regardless of whether it works or not.

    1. I've added a rather contrived example to point out usage of automatic storage, and a bit of wording related to object lifetime.

  2. Something else to look for that falls within these lines is being careful about passing already free()'d pointers to realloc() and calling functions that call free() twice with the same arguments, i.e. double fclose()

  3. In the first Compliant Example, I'd make it a point to add

    head = 0;
    

    to the code after the loop - otherwise this variable is left with a pointer to invalid memory (this may not be necessary depending on the surrounding code).

    This is just highly defensive programming that will provoke an earlier assertion failure than otherwise.

    1. Good point.  This is necessary to comply with MEM01-C. Store a new value in pointers immediately after free().  It's fixed now.

      1. Does the book set head to zero?  (Answer: no - see p167).  If not, you have to do more major surgery on this.  Either use an example that is not claiming to come from K&R or live with the fact that our preceptors did not follow every one of these guidelines.