The return values for memory allocation routines indicate the failure or success of the allocation. According to C99, {{ Wiki Markup calloc()
}}, {{malloc()
}}, and {{realloc()
}} return null pointers if the requested memory allocation fails \ [[ISO/IEC 9899:1999|AA. Bibliography#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 and in accordance with [ERR00-CPP. Adopt and implement a consistent and comprehensive error-handling policy].
By default operator new
will throw a std::bad_alloc
exception if the allocation fails. Therefore you need not check that the result of operator new
is NULL
. However, to ease conversion of code to C++, the C++ Standard ISO/IEC 14882-2003 provides a variant of operator new
that behaves like malloc()
:
...
Failing to detect allocation failures can lead to abnormal program termination and denial-of-service attacks.
If the vulnerable program references memory offset from the return value, an attacker can exploit the program to read or write arbitrary memory. This has been used to execute arbitrary code \ [[VU#159523|http://www.kb.cert.org/vuls/id/159523]\]. Wiki Markup
Rule | Severity | Likelihood | Remediation Cost | Priority | Level |
---|---|---|---|---|---|
MEM32-CPP | high | likely | medium | P18 | L1 |
...
Compass/ROSE can detect violations of this rule. In particular, it ensures that variables are compared to NULL before being used, as in EXP34-CPP. Ensure a null pointer is not dereferenced.
Related Vulnerabilities
The vulnerability in Adobe Flash \ [[VU#159523|AA. Bibliography#VU#159523] \] arises because Flash neglects to check the return value from {{ Wiki Markup 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 CERT website.
...
This rule appears in the C Secure Coding Standard as MEM32-C. Detect and handle memory allocation errors.
Bibliography
\[[ISO/IEC 9899:1999|AA. Bibliography#ISO/IEC 9899-1999]\] Section 7.20.3, "Memory management functions"
\[ Wiki Markup
[ISO/IEC 14882-2003|AA. Bibliography#ISO/IEC 14882-2003] \] Section 5.3.4
\
[[Meyers 95|AA. Bibliography#Meyers 95]\] Item 7. Be prepared for out-of-memory conditions.
\
[[MITRE|AA. Bibliography#MITRE] \] [CWE ID 252|http://cwe.mitre.org/data/definitions/252.html], "Unchecked Return Value"
\
[MITRE\] [CWE ID 391|http://cwe.mitre.org/data/definitions/ 391.html], "Unchecked Error Condition"
\
[MITRE\] [CWE ID 476|http://cwe.mitre.org/data/definitions/476.html], "NULL Pointer Dereference"
\
[MITRE\] [CWE ID 690|http://cwe.mitre.org/data/definitions/690.html], "Unchecked Return Value to NULL Pointer Dereference"
\
[MITRE\] [CWE ID 703|http://cwe.mitre.org/data/definitions/703.html], "Failure to Handle Exceptional Conditions"
\
[MITRE\] [CWE ID 754|http://cwe.mitre.org/data/definitions/754.html], "Improper Check for Unusual or Exceptional Conditions"
\[
[Seacord 05|AA. Bibliography#Seacord 05] \] Chapter 4, "Dynamic Memory Management"
\
[[VU#159523|AA. Bibliography#VU#159523]\]
...
MEM31-CPP. Free dynamically allocated memory exactly once 08. Memory Management (MEM) MEM33-CPP. Ensure that aborted constructors do not leak