Versions Compared

Key

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

Wiki Markup
According \[[ISO/IEC 9899-1999|AA. Bibliography#ISO/IEC 9899-1999]\], the behavior of a program that uses the value of a pointer that refers to space deallocated by a call to the {{free()}} or {{realloc()}} function is [undefined |BB. Definitions#undefined behavior]. (See [undefined behavior 168 |CC. Undefined Behavior#ub_168] of Annex J.)

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 may cause a hardware trap.

Accessing memory once it is freed may corrupt the data structures used to manage the heap. References to memory that has been deallocated are referred to as dangling pointers. Accessing a dangling pointer can result in exploitable vulnerabilities.

When memory is freed, its contents may remain intact and accessible because it is at the memory manager's discretion when to reallocate or recycle the freed chunk. The data at the freed location may appear valid. However, this can change unexpectedly, leading to unintended program behavior. As a result, it is necessary to guarantee that memory is not written to or read from once it is freed.

Noncompliant Code Example

Wiki Markup
This example from Kernighan and Ritchie \[[Kernighan 1988|AA. Bibliography#Kernighan 88]\] shows both the incorrect and correct techniques for deleting items from a linked list. The incorrect solution, clearly marked as wrong in the book, is bad because {{p}} is freed before the {{p->next}} is executed, so {{p->next}} reads memory that has already been freed.

Code Block
bgColor#FFCCCC
langc
for (p = head; p != NULL; p = p->next)
    free(p);

Compliant Solution

Kernighan and Ritchie also show the correct solution. To correct this error, a reference to p->next is stored in q before freeing p.

Code Block
bgColor#ccccff
langc
for (p = head; p != NULL; p = q) {
  q = p->next;
  free(p);
}
head = NULL;

Noncompliant Code Example

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

Code Block
bgColor#FFCCCC
langc
int main(int argc, const char *argv[]) {
  char *buff;

  buff = (char *)malloc(BUFFERSIZE);
  if (!buff) {
     /* Handle error condition */
  }
  /* ... */
  free(buff);
  /* ... */
  strncpy(buff, argv[1], BUFFERSIZE-1);
}

Compliant Solution

In this compliant solution do not free the memory until it is no longer required.

Code Block
bgColor#ccccff
langc
int main(int argc, const char *argv[]) {
  char *buff;

  buff = (char *)malloc(BUFFERSIZE);
  if (!buff) {
     /* Handle error condition */
  }
  /* ... */
  strncpy(buff, argv[1], BUFFERSIZE-1);
  /* ... */
  free(buff);
}

Noncompliant Code Example

Wiki Markup
In this noncompliant example ([CVE-2009-1364|http://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2009-1364]) from {{libwmf}} version 0.2.8.4, the return value of {{gdRealloc}} (a simple wrapper around {{realloc}} which 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 [ISO/IEC 9899:1999|AA. Bibliography#ISO/IEC 9899-1999] specifies that if {{realloc}} moves the area pointed to, then the original 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|http://xorl.wordpress.com/2009/05/05/cve-2009-1364-libwmf-pointer-use-after-free/]\].

Code Block
bgColor#FFCCCC
langc
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; //if the realloc fails, then we have not lost the im->clip->list value
    im->clip->max += 8;
  }
  im->clip->list[im->clip->count] = (*rect);
  im->clip->count++;

Compliant Solution

The compliant solution simply reassigns im->clip->list to the value of more after the call to realloc.

Code Block
bgColor#ccccff
langc
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 lead to the execution of arbitrary code with the permissions of the vulnerable process.

Rule

Severity

Likelihood

Remediation Cost

Priority

Level

MEM30-C

high

likely

medium

P18

L1

Automated Detection

Tool

Version

Checker

Description

Section

LDRA tool suite

Include Page
c:LDRA_V
c:LDRA_V

 

 

Section

Fortify SCA

Section

V. 5.0

 

 

Section

Splint

Include Page
c:Splint_V
c:Splint_V

 

 

Section

Compass/ROSE

 

 

 

Section

Coverity Prevent

Include Page
c:Coverity_V
c:Coverity_V
Section

USE_AFTER_FREE

Section

can detect the specific instances where Memory is deallocated more than once or Read/Write to target of a freed pointer

Section

Klocwork

Include Page
c:Klocwork_V
c:Klocwork_V
Section

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

 

Related Vulnerabilities

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

Related Guidelines

CERT C++ Secure Coding Standard: MEM30-CPP. Do not access freed memory

ISO/IEC 9899:1999 Section 7.20.3.2, "The free function"

ISO/IEC TR 24772 "DCM Dangling references to stack frames" and "XYK Dangling Reference to Heap"

MISRA Rule 17.6

MITRE CWE: CWE-416, "Use After Free"

Bibliography

Wiki Markup
\[[Kernighan 1988|AA. Bibliography#Kernighan 88]\] Section 7.8.5, "Storage Management"
\[[OWASP Freed Memory|AA. Bibliography#OWASP Freed Memory]\]
\[[Seacord 2005a|AA. Bibliography#Seacord 05]\] Chapter 4, "Dynamic Memory Management"
\[[Viega 2005|AA. Bibliography#Viega 05]\] Section 5.2.19, "Using freed memory"
\[[xorl 2009|AA. Bibliography#xorl 2009]\] ["CVE-2009-1364: LibWMF Pointer Use after free()"|http://xorl.wordpress.com/2009/05/05/cve-2009-1364-libwmf-pointer-use-after-free/]


MEM12-C. Consider using a Goto-Chain when leaving a function on error when using and releasing resources      08. Memory Management (MEM)      MEM31-C. Free dynamically allocated memory exactly once