Page History

Accessing previously dynamically allocated memory once it is freed after it has been deallocated may corrupt the data structures used to manage the heap 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 freeddeallocated, its contents may remain intact and accessible because it is at the memory manager's discretion when to reallocate or recycle the freed deallocated chunk. The data at the freed 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 freeddeallocated.

Noncompliant Code Example (free)

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

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 freeddeallocated. 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 frees deallocations are far removed, making it difficult to recognize and diagnose these 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 do not free 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], */
  delete[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 = NULL strncpy(buff.get(), argv[1], BUFSIZ-1);
  }

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

Risk Assessment

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

...