Page History

Accessing memory once it is freed may corrupt the data structures used to manage the heap. References Evaluating a pointer—including dereferencing the pointer, using it as an operand of an arithmetic operation, type casting it, and using it as the right-hand side of an assignment—into memory that has been deallocated by a memory management function is undefined behavior. Pointers to memory that has been deallocated are referred to as called dangling pointers. Accessing a dangling pointer can result in exploitable exploitable vulnerabilities.

When memory is freed, its contents may remain intact and accessible because it is It is at the memory manager's discretion when to reallocate or recycle the freed chunk. 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 may can appear valid. However, this can change unexpectedly, leading to unintended program behavior. As a result, it is necessary to guarantee that memory is not 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 Kernighan and Ritchie \[[Kernighan 88|AA. C++ References#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.

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.

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.

void f() {
  unsigned char *ptr;
  *ptr = 0;
}

Noncompliant Code Example (new and delete)

In this noncompliant code example, s is dereferenced after it has been deallocated. If this access results in a write-after-free, the vulnerability can be exploited to run arbitrary code with the permissions of the vulnerable process. Typically, dynamic memory allocations and deallocations are far removed, making it difficult to recognize and diagnose such problems.

#include <new>
 
struct S {
  void f();
};
 
void g() noexcept(false) {
  S *s = new S;
  // ...
  delete s;
  // ...
  s->f();
}

The function g() is marked noexcept(false) to comply with MEM52-CPP. Detect and handle memory allocation errors.

Compliant Solution (new and delete)

In this compliant solution, the dynamically allocated memory is not deallocated until it is no longer required.

#include <new>

struct S {
  void f();
};

void g() noexcept(false) {
  S *s = new S;
  // ...
  s->f();
  delete s;
}

Compliant Solution (Automatic Storage Duration)

When possible, use automatic storage duration instead of dynamic storage duration. Since s is not required to live beyond the scope of g(), this compliant solution uses automatic storage duration to limit the lifetime of s to the scope of g().

struct S {
  void f();
};

void g() {
  S s;
  // ...
  s.f();
}

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.

#include <iostream>
#include <memory>
#include <cstring>
 

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

  buff = s = "";
  if (argc > 1) {
    enum { BufferSize = 32 };
    try {
      std::unique_ptr<char[]> buff(new char[BUFSIZBufferSize]);
  /* ... */
  delete[] buff;
  /*    std::memset(buff.get(), 0, BufferSize);
      // ... */
  
      s = std::strncpy(buff.get(), argv[1], BufferSize BUFSIZ- 1);
    } catch (std::bad_alloc &) {
      // Handle error
    }
  }

  std::cout << s << std::endl;
}

This code always creates a null-terminated byte string, despite its use of strncpy(), because it leaves the final char in the buffer set to 0.

Compliant Solution (std::unique_ptr)

In this compliant solution do not free the memory until it is no longer required, the lifetime of the buff object extends past the point at which the memory managed by the object is accessed.

#include <iostream>
#include <memory>
#include <cstring>
 
int main(int argc, const char *argv[]) {
  std::unique_ptr<char[]> buff;
  const char *buff;

  buff = s = "";

  if (argc > 1) {
    enum { BufferSize = 32 };
    try {
      buff.reset(new char[BUFSIZBufferSize]);
      /*std::memset(buff.get(), 0, BufferSize);
      // ... */
  
      s = std::strncpy(buff.get(), argv[1], BufferSize BUFSIZ- 1);
    } catch (std::bad_alloc &) {
      // Handle error
    }
  }

  std::cout << s << std::endl;
}

Compliant Solution

In this compliant solution, a variable with automatic storage duration of type std::string is used in place of the std::unique_ptr<char[]>, which reduces the complexity and improves the security of the solution.

#include <iostream>
#include <string>
 
int main(int argc, const char *argv[]) {
  std::string str;

  if (argc > 1) {
    str = argv[1];
  }

  std::cout << str << std::endl;
}

Noncompliant Code Example (std::string::c_str())

In this noncompliant code example, std::string::c_str() is being called on a temporary std::string object. The resulting pointer will point to released memory once the std::string object is destroyed at the end of the assignment expression, resulting in undefined behavior when accessing elements of that pointer.

#include <string>
 
std::string str_func();
void display_string(const char *);
 
void f() {
  const char *str = str_func().c_str();
  display_string(str);  /* Undefined behavior */
  delete[] buff;
  buff = NULL;
}

Risk Assessment

}

Compliant solution (std::string::c_str())

In this compliant solution, a local copy of the string returned by str_func() is made to ensure that string str will be valid when the call to display_string() is made.

#include <string>
 
std::string str_func();
void display_string(const char *s);

void f() {
  std::string str = str_func();
  const char *cstr = str.c_str();
  display_string(cstr);  /* ok */
}

Noncompliant Code Example

In this noncompliant code example, an attempt is made to allocate zero bytes of memory through a call to operator new(). If this request succeeds, operator new() is required to return a non-null pointer value. However, according to the C++ Standard, [basic.stc.dynamic.allocation], paragraph 2 [ISO/IEC 14882-2014], attempting to dereference memory through such a pointer results in undefined behavior.

#include <new>

void f() noexcept(false) {
  unsigned char *ptr = static_cast<unsigned char *>(::operator new(0));
  *ptr = 0;
  // ...
  ::operator delete(ptr);
}

Compliant Solution

The compliant solution depends on programmer intent. If the programmer intends to allocate a single unsigned char object, the compliant solution is to use new instead of a direct call to operator new(), as this compliant solution demonstrates.

void f() noexcept(false) {
  unsigned char *ptr = new unsigned char;
  *ptr = 0;
  // ...
  delete ptr;
}

Compliant Solution

If the programmer intends to allocate zero bytes of memory (perhaps to obtain a unique pointer value that cannot be reused by any other pointer in the program until it is properly released), then instead of attempting to dereference the resulting pointer, the recommended solution is to declare ptr as a void *, which cannot be dereferenced by a conforming implementation.

#include <new>

void f() noexcept(false) {
  void *ptr = ::operator new(0);
  // ...
  ::operator delete(ptr);
}

Risk Assessment

Reading previously dynamically allocated memory after it has been deallocated 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 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.

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

Related Vulnerabilities

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

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

Related Guidelines

...

Other Languages

...

...

...

\[[Henricson 97|AA. C++ References#Henricson 97]\] Rule 8.3 Do not access a pointer or reference to a deleted object
\[[ISO/IEC 9899:1999|AA. C++ References#ISO/IEC 9899-1999]\] Section 7.20.3.2, "The {{free}} function"
\[[ISO/IEC PDTR 24772|AA. C++ References#ISO/IEC PDTR 24772]\] "DCM Dangling references to stack frames" and "XYK Dangling Reference to Heap"
\[[Kernighan 88|AA. C++ References#Kernighan 88]\] Section 7.8.5, "Storage Management"
\[[MISRA 04|AA. C++ References#MISRA 04]\] Rule 17.6
\[[MITRE 07|AA. C++ References#MITRE 07]\] [CWE ID 416|http://cwe.mitre.org/data/definitions/416.html], "Use After Free"
\[[OWASP Freed Memory|AA. C++ References#OWASP Freed Memory]\]
\[[Seacord 05a|AA. C++ References#Seacord 05]\] Chapter 4, "Dynamic Memory Management"
\[[Viega 05|AA. C++ References#Viega 05]\] Section 5.2.19, "Using freed memory"

Bibliography

...

Image Added Image Added Image AddedMEM11-CPP. Do not use volatile as a synchronization primitive      08. Memory Management (MEM)      MEM31-CPP. Free dynamically allocated memory exactly once