The pointer argument to the
reallocfunction does not match a pointer earlier returned by a memory management function, or the space has been deallocated by a call to
See also undefined behavior 179.
Freeing memory that is not allocated dynamically can result in heap corruption and other serious errors. Do not call
free() on a pointer other than one returned by a standard memory allocation function, such as
A similar situation arises when
realloc() is supplied a pointer to non-dynamically allocated memory. The
realloc() function is used to resize a block of dynamic memory. If
realloc() is supplied a pointer to memory not allocated by a standard memory allocation function, the behavior is undefined. One consequence is that the program may terminate abnormally.
This rule does not apply to null pointers. The C Standard guarantees that if
free() is passed a null pointer, no action occurs.
Noncompliant Code Example
This noncompliant code example sets
c_str to reference either dynamically allocated memory or a statically allocated string literal depending on the value of
argc. In either case,
c_str is passed as an argument to
free(). If anything other than dynamically allocated memory is referenced by
c_str, the call to
free(c_str) is erroneous.
This compliant solution eliminates the possibility of
c_str referencing memory that is not allocated dynamically when passed to
Noncompliant Code Example (
In this noncompliant example, the pointer parameter to
buf, does not refer to dynamically allocated memory:
Compliant Solution (
In this compliant solution,
buf refers to dynamically allocated memory:
realloc() will behave properly even if
malloc() failed, because when given a null pointer,
realloc() behaves like a call to
The consequences of this error depend on the implementation, but they range from nothing to arbitrary code execution if that memory is reused by
|Axivion Bauhaus Suite|
|CertC-MEM34||Can detect memory deallocations for stack objects|
|clang-analyzer-unix.Malloc||Checked by |
Free non-heap variable
Can detect some violations of this rule
Identifies calls to
|LDRA tool suite|
407 S, 483 S, 644 S, 645 S, 125 D
|Do not free resources using invalid pointers|
|Parasoft Insure++||Runtime analysis|
|Polyspace Bug Finder|
Checks for invalid free of pointer
|2721, 2722, 2723|
|unclassified ("free expects a free-able address")|
Exhaustively verified (see one compliant and one non-compliant example).
CVE-2015-0240 describes a vulnerability in which an uninitialized pointer is passed to
TALLOC_FREE(), which is a Samba-specific memory deallocation macro that wraps the
talloc_free() function. The implementation of
talloc_free() would access the uninitialized pointer, resulting in a remote exploit.
Search for vulnerabilities resulting from the violation of this rule on the CERT website.
Key here (explains table format and definitions)
|CERT C Secure Coding Standard||MEM31-C. Free dynamically allocated memory when no longer needed||Prior to 2018-01-12: CERT: Unspecified Relationship|
|CERT C||MEM51-CPP. Properly deallocate dynamically allocated resources||Prior to 2018-01-12: CERT: Unspecified Relationship|
|ISO/IEC TS 17961||Reallocating or freeing memory that was not dynamically allocated [xfree]||Prior to 2018-01-12: CERT: Unspecified Relationship|
|CWE 2.11||CWE-590, Free of Memory Not on the Heap||2017-07-10: CERT: Exact|
|[ISO/IEC 9899:2011]||Subclause J.2, "Undefined Behavior"|
|[Seacord 2013b]||Chapter 4, "Dynamic Memory Management"|