Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.
Comment: Updated references from C11->C23

Before the lifetime of the last pointer that stores the return value of a call to a standard memory allocation function has ended, it must be matched by a call to free() with that pointer value.

Noncompliant Code Example

In this noncompliant example, the object allocated by the call to malloc() is not freed before the end of the lifetime of the last pointer text_buffer referring to the object:

Freeing memory multiple times has similar consequences to accessing memory after it is freed. The underlying data structures that manage the heap can become corrupted in a way that could introduce security vulnerabilities into a program. These types of issues are referred to as double-free vulnerabilities. In practice, double-free vulnerabilities can be exploited to execute arbitrary code. VU#623332, which describes a double-free vulnerability in the MIT Kerberos 5 function krb5_recvauth(), is one example.

To eliminate double-free vulnerabilities, it is necessary to guarantee that dynamic memory is freed exactly one time. Programmers should be wary when freeing memory in a loop or conditional statement; if coded incorrectly, these constructs can lead to double-free vulnerabilities. It is also a common error to misuse the realloc() function in a manner that results in double-free vulnerabilities (see MEM04-A. Do not perform zero length allocations).

Non-Compliant Code Example

In this example, the memory referred to by x may be freed twice: once if error_condition is true and again at the end of the code.

Code Block
bgColor#FFCCCC
langc
#include <stdlib.h>
 
enum { BUFFER_SIZE = 32 };

int f(void) {
  char *text_buffer = (char *)malloc(BUFFER_SIZE); 
  if (text_buffer
size_t number;
int error_condition = 0;

/* initialize number */

int *x = (int *)malloc(number * sizeof(int));
if (x == NULL) {
    return -1;
  }
  return 0;
}

Compliant Solution

In this compliant solution, the pointer is deallocated with a call to free():

Code Block
bgColor#ccccff
langc
#include <stdlib.h>

enum { BUFFER_SIZE = 32 };

int f(void) {
  char *text_buffer = (char *)malloc(BUFFER_SIZE); 
  if (text_buffer == NULL/* Handle Allocation Error */
}
/* ... */
if (error_condition == 1) {
  /* Handle Error Condition*/  return -1;
  }
 
  free(xtext_buffer);
}
/* ... */
free(x);

Compliant Solution

  return 0;
}

Exceptions

MEM31-C-EX1: Allocated memory does not need to be freed if it is assigned to a pointer whose lifetime includes program termination. The following code example illustrates a pointer that stores the return value from malloc() in a static variable:Only free a pointer to dynamic memory referred to by x once. This is accomplished by removing the call to free() in the section of code executed when error_condition is true.

Code Block
bgColor#ccccff
langc
#include <stdlib.h>
 
enum { BUFFER_SIZE = 32 };

int f(void) {
  static char *text_buffer = NULL;
  if (text_buffer == NULL) {
    text_buffer = (char *)malloc(BUFFER_SIZE); 
    if (text_buffer
size_t number;
int error_condition = 0;

/* initialize number */

if (number > SIZE_MAX/sizeof(int)) {
   /* handle overflow */
  }
int *x = (int *)malloc(number * sizeof(int));
if (x == NULL) {
  /* Handle Allocation Error */
}
/* ... */
if (error_condition == 1) {
  /* Handle Error Condition*/
}
/* ... */
free(x);
x = NULL;

Note that this solution checks for numeric overflow (see INT32-C. Ensure that operations on signed integers do not result in overflow).

Risk Assessment

 return -1;
    }
  }
  return 0;
}

Risk Assessment

Failing to free memory can result in the exhaustion of system memory resources, which can lead to a denial-of-service attackFreeing memory multiple times can result in an attacker executing arbitrary code with the permissions of the vulnerable process.

Rule

Severity

Likelihood

Remediation Cost

Priority

Level

MEM31-C

high

Medium

probable

Probable

medium

Medium

P12

P8

L1

L2

Automated Detection

...

The LDRA tool suite V 7.6.0 is able to detect violations of this rule.

The Fortify Source Code Analysis Suite Double Free detects instances of memory being freed more than once.

...

Tool

Version

Checker

Description

Astrée
Include Page
Astrée_V
Astrée_V

Supported, but no explicit checker
Axivion Bauhaus Suite

Include Page
Axivion Bauhaus Suite_V
Axivion Bauhaus Suite_V

CertC-MEM31Can detect dynamically allocated resources that are not freed
CodeSonar
Include Page
CodeSonar_V
CodeSonar_V

ALLOC.LEAK

Leak

Compass/ROSE


Coverity

Include Page
Coverity_V
Coverity_V

RESOURCE_LEAK

ALLOC_FREE_MISMATCH

Finds resource leaks from variables that go out of scope while owning a resource

...

Cppcheck
 
Include Page
Cppcheck_V
Cppcheck_V
memleak
leakReturnValNotUsed
leakUnsafeArgAlloc
memleakOnRealloc
Doesn't use return value of memory allocation function
Cppcheck Premium

Include Page
Cppcheck Premium_V
Cppcheck Premium_V

memleak
leakReturnValNotUsed
leakUnsafeArgAlloc
memleakOnRealloc
Doesn't use return value of memory allocation function
Helix QAC

Include Page
Helix QAC_V
Helix QAC_V

DF2706, DF2707, DF2708

C++3337, C++3338


Klocwork
Include Page
Klocwork_V
Klocwork_V
CL.FFM.ASSIGN
CL.FFM.COPY
CL.SHALLOW.ASSIGN
CL.SHALLOW.COPY
FMM.MIGHT
FMM.MUST

LDRA tool suite
Include Page
LDRA_V
LDRA_V

50 D

Partially implemented
Parasoft C/C++test
Include Page
Parasoft_V
Parasoft_V

CERT_C-MEM31-a

Ensure resources are freed
Parasoft Insure++

Runtime analysis
PC-lint Plus

Include Page
PC-lint Plus_V
PC-lint Plus_V

429

Fully supported

Polyspace Bug Finder

Include Page
Polyspace Bug Finder_V
Polyspace Bug Finder_V

CERT C: Rule MEM31-CChecks for memory leak (rule fully covered)


PVS-Studio

Include Page
PVS-Studio_V
PVS-Studio_V

V773
SonarQube C/C++ Plugin
Include Page
SonarQube C/C++ Plugin_V
SonarQube C/C++ Plugin_V
S3584
Splint

Include Page
Splint_V
Splint_V



TrustInSoft Analyzer

Include Page
TrustInSoft Analyzer_V
TrustInSoft Analyzer_V

mallocExhaustively verified.

Related Vulnerabilities

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

References

Wiki Markup
\[[VU#623332|AA. C References#VU623332]\]
\[[MIT 05|AA. C References#MIT 05]\]
\[[OWASP, Double Free|AA. C References#OWASP Double Free]\]
\[[MITRE 07|AA. C References#MITRE 07]\] [CWE ID 415|http://cwe.mitre.org/data/definitions/415.html], "Double Free"
\[[Viega 05|AA. C References#Viega 05]\] "Doubly freeing memory"

Related Guidelines

Key here (explains table format and definitions)

Taxonomy

Taxonomy item

Relationship

ISO/IEC TR 24772:2013Memory Leak [XYL]Prior to 2018-01-12: CERT: Unspecified Relationship
ISO/IEC TS 17961Failing to close files or free dynamic memory when they are no longer needed [fileclose]Prior to 2018-01-12: CERT: Unspecified Relationship
CWE 2.11CWE-401, Improper Release of Memory Before Removing Last Reference ("Memory Leak")2017-07-05: CERT: Exact
CWE 2.11CWE-4042017-07-06: CERT: Rule subset of CWE
CWE 2.11CWE-4592017-07-06: CERT: Rule subset of CWE
CWE 2.11CWE-7712017-07-06: CERT: Rule subset of CWE
CWE 2.11CWE-7722017-07-06: CERT: Rule subset of CWE

CERT-CWE Mapping Notes

Key here for mapping notes

CWE-404/CWE-459/CWE-771/CWE-772 and FIO42-C/MEM31-C

Intersection( FIO42-C, MEM31-C) = Ø

CWE-404 = CWE-459 = CWE-771 = CWE-772

CWE-404 = Union( FIO42-C, MEM31-C list) where list =

  • Failure to free resources besides files or memory chunks, such as mutexes)

Bibliography

[ISO/IEC 9899:2024]Subclause 7.24.3, "Memory Management Functions"


...

Image Added Image Added Image AddedImage Removed      08. Memory Management (MEM)       MEM32-C. Detect and handle memory allocation errors