Page History

Accessing previously dynamically allocated memory after it has been deallocated may corrupt the data structures used to manage the free store or other types of storage. References to memory that has been deallocated are referred to as dangling pointers. Accessing a dangling pointer can result in exploitable vulnerabilities.

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 memory is deallocated, its contents may remain intact and accessible because it is at the memory manager's discretion when to reallocate or recycle the deallocated chunk. The data at the deallocated 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 deallocated.

Noncompliant Code Example (free)

This example from Kernighan and Ritchie [Kernighan 88] shows both the incorrect and correct techniques for removing items from a linked list. The incorrect solution, clearly marked as wrong in the book, is bad because p is deallocated before the p->next is executed, so p->next reads memory that has already been deallocated.

for (p = head; p != NULL; p = p->next)
    free(p);

Compliant Solution (free)

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

for (p = head; p != NULL; p = q) {
  q = p->next;
  free(p);
}
head = NULL;

Noncompliant Code Example (new and delete)

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

int main(int argc, const char *argv[]) {
  char *buff;

  buff = new char[BUFSIZ];
  // ...
  delete[] buff;
  // ...
  strncpy(buff, argv[1], BUFSIZ-1);
}

Compliant Solution (new and delete)

In this compliant solution the dynamically allocated memory isn't deallocated until it is no longer required.

int main(int argc, const char *argv[]) {
  char *buff;

  buff = new char[BUFSIZ];
  // ...
  strncpy(buff, argv[1], BUFSIZ-1);
  // ...
  delete[] buff;
  buff = nullptr;
}

Noncompliant Code Example (std::unique_ptr)

In the following noncompliant code example, the dynamically allocated memory managed by the buff object is accessed after it has been implicitly deallocated by the object's destructor.

int main(int argc, const char *argv[]) {
  const char *s = "";

  if (1 < argc) {
    std::unique_ptr<char[]> buff (new char [BUFSIZ]);
    // ...
    s = strncpy(buff.get(), argv[1], BUFSIZ-1);
  }

  std::cout << s << '\n';
}

Compliant Solution (std::unique_ptr)

In this compliant solution the lifetime of the buff object extends past the point the memory managed by the object is accessed.

int main(int argc, const char *argv[]) {
  std::unique_ptr<char[]> buff;
  const char *s = "";

  if (1 < argc) {
    buff.reset(new char [BUFSIZ]);
    // ...
    s = strncpy(buff.get(), argv[1], BUFSIZ-1);
  }

  std::cout << s << '\n';
}

Risk Assessment

Reading previously dynamically allocated memory after it has been deallocated can lead to abnormal program termination and denial-of-service attacks. Writing memory that has been deallocated can lead to the execution of 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.

Splint Version 3.1.1 can detect violations of this rule.

Compass/ROSE can detect violations of the rule.

The Coverity Prevent Version 5.0 USE_AFTER_FREE checker can detect the specific instances where Memory is deallocated more than once or Read/Write to target of a freed pointer.

Klocwork Version 8.0.4.16 can detect violations of this rule with the UFM.DEREF.MIGHT, UFM.DEREF.MUST, UFM.FFM.MIGHT, UFM.FFM.MUST, UFM.PARAMPASS.MIGHT, UFM.PARAMPASS.MUST, UFM.RETURN.MIGHT, UFM.RETURN.MUST, UFM.USE.MIGHT, and UFM.USE.MUST checkers.

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 MEM30-C. Do not access freed memory.

Bibliography

[Henricson 97] Rule 8.3 Do not access a pointer or reference to a deleted object
[ISO/IEC 9899:1999] Section 7.20.3.2, "The free function"
[ISO/IEC PDTR 24772] "DCM Dangling references to stack frames" and "XYK Dangling Reference to Heap"
[Kernighan 88] Section 7.8.5, "Storage Management"
[MISRA 04] Rule 17.6
[MITRE 07] CWE ID 416, "Use After Free"
[OWASP Freed Memory]
[Seacord 05a] Chapter 4, "Dynamic Memory Management"
[Viega 05] Section 5.2.19, "Using freed memory"

MEM13-CPP. Use smart pointers instead of raw pointers for resource management      08. Memory Management (MEM)      MEM31-CPP. Free dynamically allocated memory exactly once