Page History

The default memory allocation operator, ::operator new(std::size_t), throws a std::bad_alloc exception if the allocation fails. Therefore, you need not check whether calling ::operator new(std::size_t) results in nullptr. The nonthrowing form, ::operator new(std::size_t, const std::nothrow_t &), does not throw an exception if the allocation fails but instead returns nullptr. The same behaviors apply for the operator new[] versions of both allocation functions. Additionally, the default allocator object (std::allocator) uses ::operator new(std::size_t) to perform allocations and should be treated similarly.

T *p1 = new T; // Throws std::bad_alloc if allocation fails
T *p2 = new (std::nothrow) T; // Returns nullptr if allocation fails

T *p3 = new T[1]; // Throws std::bad_alloc if the allocation fails
T *p4 = new (std::nothrow) T[1]; // Returns nullptr if the allocation fails

Furthermore, operator new[] can throw an error of type std::bad_array_new_length, a subclass of std::bad_alloc, if the size argument passed to new is negative or excessively large.

When using the nonthrowing form, it is imperative to check that the return value is not nullptr before accessing the resulting pointer. When using either form, be sure to comply with ERR50-CPP. Do not abruptly terminate the program.

Noncompliant Code Example

In this noncompliant code example, an array of int is created using ::operator new[](std::size_t) and the results of the allocation are not checked. The function is marked as noexcept, so the caller assumes this function does not throw any exceptions. Because ::operator new[](std::size_t) can throw an exception if the allocation fails, it could lead to abnormal termination of the program.

#include <cstring>
 
void f(const int *array, std::size_t size) noexcept {
  int *copy = new int[size];
  std::memcpy(copy, array, size * sizeof(*copy));
  // ...
  delete [] copy;
}

Compliant Solution (std::nothrow)

When using std::nothrow, the new operator

The return values for memory allocation routines indicate the failure or success of the allocation. According to C99, {{calloc()}}, {{malloc()}}, and {{realloc()}} return null pointers if the requested memory allocation fails \[[ISO/IEC 9899:1999|AA. C++ References#ISO/IEC 9899-1999]\]. Failure to detect and properly handle memory management errors can lead to unpredictable and unintended program behavior. As a result, it is necessary to check the final status of memory management routines and handle errors appropriately.

The following table shows the possible outcomes of the standard memory allocation functions.

Noncompliant Code Example

In this example, input_string is copied into dynamically allocated memory referenced by str. However, the result of malloc() is not checked before str is referenced. Consequently, if malloc() fails, the program abnormally terminates.

char *input_string;

/* initialize input_string */

size_t size = strlen(input_string) + 1;
char *str = (char *)malloc(size);
strcpy(str, input_string);
/* ... */
free(str);
str = NULL;

Compliant Solution

The malloc() function as well as the other memory allocation functions, returns either a null pointer or a pointer to the allocated space. Always test the returned pointer to ensure it is not NULL before nullptr before referencing the pointer. Handle This compliant solution handles the error condition appropriately when the returned pointer is NULL nullptr.

#include <cstring>
char *input_string;

/* initialize input_string */

#include <new>
 
void f(const int *array, std::size_t size) noexcept {
  int = strlen(input_string) + 1;
char *str = (char *)malloc(size);
if (str == NULL) {
  /* Handle allocation error */
}
else {
  strcpy(str, input_string);
  /* ... */
  free(str);
  str = NULL;

Noncompliant Code Example

*copy = new (std::nothrow) int[size];
  if (!copy) {
    // Handle error
    return;
  }
  std::memcpy(copy, array, size * sizeof(*copy));
  // ...
  delete [] copy;
}

Compliant Solution (std::bad_alloc)

Alternatively, you can use ::operator new[] without std::nothrow and instead catch a std::bad_alloc exception if sufficient memory cannot be allocated.

#include <cstring>
#include <new>
 
void f(const int *array, std::size_t size) noexcept {
  int *copy;
  try {
    copy = new int[size];
  } catch(std::bad_alloc) {
    // Handle error
    return;
  }
  // At this point, copy has been initialized to allocated memory
  std::memcpy(copy, array, size * sizeof(*copy));
  // ...
  delete [] copy;
}

Compliant Solution (noexcept(false))

If the design of the function is such that the caller is expected to handle exceptional situations, it is permissible to mark the function explicitly as one that may throw, as in this compliant solution. Marking the function is not strictly required, as any function without a noexcept specifier is presumed to allow throwing.

#include <cstring>
 
void f(const int *array, std::size_t size) noexcept(false) {
  int *copy = new int[size];
  // If the allocation fails, it will throw an exception which the caller
  // will have to handle.
  std::memcpy(copy, array, size * sizeof(*copy));
  // ...
  delete [] copy;
}

Noncompliant Code Example

In this noncompliant code example, two memory allocations are performed within the same expression. Because the memory allocations are passed as arguments to a function call, an exception thrown as a result of one of the calls to new could result This noncompliant code example calls realloc() to resize the memory referred to by p. However, if realloc() fails, it returns a null pointer. Consequently, the connection between the original block of memory and p is severed, resulting in a memory leak.

void *p;
size_t new_size;

/* initialize new_size */

p = realloc(p, new_size);
if (p == NULL)   {
 /* Handle error */
}

When using realloc(), it is important to account for zero-byte allocations (see MEM04-CPP. Do not perform zero length allocations).

Compliant Solution

struct A { /* ... */ };
struct B { /* ... */ }; 
 
void g(A *, B *);
void f() {
  g(new A, new B);
}

Consider the situation in which A is allocated and constructed first, and then B is allocated and throws an exception. Wrapping the call to g() in a try/catch block is insufficient because it would be impossible to free the memory allocated for A.

This noncompliant code example also violates EXP50-CPP. Do not depend on the order of evaluation for side effects, because the order in which the arguments to g() are evaluated is unspecified.

Compliant Solution (std::unique_ptr)

In this compliant solution, a std::unique_ptr is used to manage the resources for the A and B objects with RAII. In the situation described by the noncompliant code example, B throwing an exception would still result in the destruction and deallocation of the A object when then std::unique_ptr<A> was destroyedIn this compliant solution, the result of realloc() is assigned to the temporary pointer q and validated before assigning it to the original pointer p.

#include <memory>
 
struct A { /* ... */ };
struct B { /* ... */ }; 
 
void g(std::unique_ptr<A> a, std::unique_ptr<B> b);
void f() {
  g(std::make_unique<A>(), std::make_unique<B>());
}

Compliant Solution (References)

When possible, the more resilient compliant solution is to remove the memory allocation entirely and pass the objects by reference instead.

struct A { /* ... */ };
struct B { /* ... */ }; 
 
void g(A &a, B &b);
void f() {
  A a;
  B b;
  g(a, b);
}
void *p;
void *q;
size_t new_size;

/* initialize new_size */

q = realloc(p, new_size);
if (q == NULL)   {
 /* Handle error */
}
else {
  p = q;
}

Risk Assessment

Failing to detect allocation failures can lead to abnormal program termination and denial-of-service attacks.

Wiki MarkupIf the vulnerable program references memory offset from the return value, an attacker can exploit the program to read or write arbitrary memory. This vulnerability has been used to execute arbitrary code \[ [VU#159523|http://www.kb.cert.org/vuls/id/159523]\].

Automated Detection

...

...

Related Vulnerabilities

The vulnerability in Adobe Flash [VU#159523] arises because Flash neglects to check the return value from calloc(). Even though calloc() returns NULL, Flash does not attempt to read or write to the return value. Instead, it attempts to write to an offset from the return value. Dereferencing NULL usually results in a program crash, but dereferencing an offset from NULL allows an exploit to succeed without crashing the

Related Vulnerabilities

Wiki MarkupThe vulnerability in Adobe Flash \[[VU#159523|AA. C++ References#VU#159523]\] arises because Flash neglects to check the return value from {{calloc()}}. Even though {{calloc()}} returns NULL, Flash does not attempt to read or write to the return value, but rather attempts to write to an offset from the return value. Dereferencing NULL usually results in a program crash, but dereferencing an offset from NULL allows an exploit to succeed without crashing the program.

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

Other Languages

...

Related Guidelines

...

...

Bibliography

References

...

...

...

Image Added Image Added Image Added management functions" \[[MITRE 07|AA. C++ References#MITRE 07]\] [CWE ID 476|http://cwe.mitre.org/data/definitions/476.html], "NULL Pointer Dereference," and [CWE ID 252|http://cwe.mitre.org/data/definitions/252.html], "Unchecked Return Value" \[[Seacord 05|AA. C++ References#Seacord 05]\] Chapter 4, "Dynamic Memory Management" \[[VU#159523|AA. C++ References#VU#159523]\]MEM31-CPP. Free dynamically allocated memory exactly once      08. Memory Management (MEM)      MEM34-CPP. Only free memory allocated dynamically