Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

To avoid these situations, memory should be allocated and freed at the same level of abstraction and, ideally, in the same code module. This includes the use of the following memory allocation and deallocation functions described in C99, Section 7.2023.3 of the C standard [ISO/IEC 9899:19992011]:

Code Block

void *malloc(size_t size);

void *calloc(size_t nmemb, size_t size);

void *realloc(void *ptr, size_t size);

void *aligned_alloc(size_t alignment, size_t size);
 
void free(void *ptr);

Failing to follow this recommendation has led to real-world vulnerabilities. For example, freeing memory in different modules resulted in a vulnerability in MIT Kerberos 5 [MIT 2004]. The MIT Kerberos 5 code in this case contained error-handling logic, which freed memory allocated by the ASN.1 decoders if pointers to the allocated memory were non-null. However, if a detectable error occurred, the ASN.1 decoders freed the memory that they had allocated. When some library functions received errors from the ASN.1 decoders, they also attempted to free the same memory, resulting in a double-free vulnerability.

...

Code Block
bgColor#FFcccc
langc

enum { MIN_SIZE_ALLOWED = 32 };

int verify_size(char *list, size_t size) {
  if (size < MIN_SIZE_ALLOWED) {
    /* Handle Error Condition */
    free(list);
    return -1;
  }
  return 0;
}

void process_list(size_t number) {
  char *list = (char *)malloc(number);
  if (list == NULL) {
    /* Handle Allocation Error */
  }

  if (verify_size(list, number) == -1) {
      free(list);
      return;
  }

  /* Continue Processing list */

  free(list);
}

The call to free memory in the verify_size() function takes place in a subroutine of the process_list() function, at a different level of abstraction from the allocation, resulting in a violation of this recommendation. The memory deallocation also occurs in error-handling code, which is frequently not as well tested as "green paths" through the code.

...

To correct this problem, the error-handling code in verify_size() is modified so that it no longer frees list. This change ensures that list is freed only once, at the same level of abstraction, in the process_list() function.

Code Block
bgColor#ccccff
langc

enum { MIN_SIZE_ALLOWED = 32 };

int verify_size(const char *list, size_t size) {
  if (size < MIN_SIZE_ALLOWED) {
    /* Handle Error Condition */
    return -1;
  }
  return 0;
}

void process_list(size_t number) {
  char *list = (char *)malloc(number);

  if (list == NULL) {
    /* Handle Allocation Error */
  }

  if (verify_size(list, number) == -1) {
      free(list);
      return;
  }

  /* Continue Processing list */

  free(list);
}

...

sectioncan

Can detect violations of this rule with CERT C Rule Pack

section

.

could

Could detect possible violations by reporting any function that has malloc() or free() but not both. This would catch some false positives, as there would be no way to tell if malloc() and free() are

'

at the same level of abstraction

'

if they are in different functions

section

.

can

Can detect the specific instances where

Memory

memory is deallocated more than once or

Read

read/

Write

written to the target of a freed pointer.

Tool

Version

Checker

Description

LDRA tool suite

Include Page
LDRA_V
LDRA_V
section

50 D

section

Partially

Implemented section

implemented.

Fortify SCA

section

V. 5.0

 

Section

Compass/ROSE

 

 

Section

Coverity Prevent

Include Page
Coverity_V
Coverity_V
section

USE_AFTER_FREE

Section

Related Vulnerabilities

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

...

CERT C++ Secure Coding Standard: MEM11-CPP. Allocate and free memory in the same module, at the same level of abstraction

ISO/IEC 9899:19992011 Section 7.2023.3, "Memory Management Functionsmanagement functions"

ISO/IEC TR 24772 "XYL Memory Leakleak"

MITRE CWE: CWE-416, "Use After Freeafter free"

MITRE CWE: CWE-415, "Double Freefree"

Bibliography

[MIT 2004]
[Plakosh 2005]
[Seacord 2005a] Chapter 4, "Dynamic Memory Management"

...