Page History

...

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 and are seldom this obvious. Typically, dynamic memory allocations and deallocations are far removed, making it difficult to recognize and diagnose such problems.

...

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

Compliant Solution (new and delete)

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

#include <new>

struct S {
  void f();
};

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

Compliant Solution (Automatic Storage Duration)

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

struct S {
  void f();
};

void f() {
  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 *s = "";
  if (argc > 1) {
    enum { BUFFER_SIZE = 32 };
    try {
      std::unique_ptr<char[]> buff(new char[BUFFER_SIZE]);
      // ...
      s = std::strncpy(buff.get(), argv[1], BUFFER_SIZE - 1);
    } catch (std::bad_alloc &) {
      // Handle error
    }
  }

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

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:

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

  if (argc > 1) {
    enum { BUFFER_SIZE = 32 };
    try {
      buff.reset(new char[BUFFER_SIZE]);
      // ...
      s = std::strncpy(buff.get(), argv[1], BUFFER_SIZE - 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 increases 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 someStringReturningFunction();
void displayString(const char *);
 
void f() {
  const char *str = someStringReturningFunction().c_str();
  displayString(str);  /* Undefined behavior */
}

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

In this compliant solution, a local copy of the string returned by someStringReturningFunction() is made that ensures the string str will be valid when the call to displayString is made:

#include <string>
 
std::string someStringReturningFunction();
void displayString(const char *s);

void f() {
  std::string str = someStringReturningFunction();
  const char *str = str.c_str();
  displayString(str);  /* 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 nonnull pointer value. However, according to the C++ Standard, [basic.stc.dynamic.allocation], paragraph 2 [ISO/IEC 14882-2014], attempting to indirect 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 intended 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:

...

#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 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

Related Vulnerabilities

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

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

Related Guidelines

Bibliography

...