Page History

Wiki MarkupDynamic memory management is a common source of programming flaws that can lead to security vulnerabilities. Decisions regarding how dynamic memory is allocated, used, and deallocated are the burden of the programmer. Poor memory management can lead to security issues , such as heap-buffer overflows, dangling pointers, and double-free issues \[ [Seacord 05a|AA. References#Seacord 05]\2013]. From the programmer's perspective, memory management involves allocating memory, reading and writing to memory, and deallocating memory.

Allocating and freeing memory in different modules and levels of abstraction may make it difficult to determine when and if a block of memory has been freed, leading to programming defects, such as memory leaks, double-free vulnerabilities, accessing freed memory, or writing to freed or unallocated memory.unmigrated-wiki-markup

To avoid these situations, memory should be allocated and freed at the same level of abstraction and, and ideally , in the same code module. This includes the use of the following memory allocation and deallocation functions described in C99 Section subclause 7.2023.3 \[of the C Standard [ISO/IEC 9899:1999|AA. References#ISO/IEC 9899-1999]\2011]:

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);

Wiki MarkupFailing 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 04|AA. References#MIT 04]\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.

Noncompliant Code Example

This noncompliant code example shows a double-free vulnerability resulting from memory being allocated and freed at differing levels of abstraction. In this example, memory for the list array is allocated in the process_list() function. The array is then passed to the verify_listsize() function that performs error checking on the size of the list. If the size of the list is below a minimum size, the memory allocated to the list is freed, and the function returns to the caller. The calling function then frees this same memory again, resulting in a double-free and potentially exploitable vulnerability.

enum { MIN_SIZE_ALLOWED = 32 };

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

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

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

  /* Continue Processingprocessing list */

  free(list);
}

The call to free memory in the verify_listsize() 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_listsize() 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.

enum { MIN_SIZE_ALLOWED = 32 };

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

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

  if (list == NULL) {
    /* Handle Allocationallocation Errorerror */
  }

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

  /* Continue Processingprocessing list */

  free(list);
}

Risk Assessment

The mismanagement of memory can lead to freeing memory multiple times or writing to already freed memory. Both of these coding errors can result in an attacker executing arbitrary code with the permissions of the vulnerable process. Memory management errors can also lead to resource depletion and denial-of-service attacks.

Automated Detection

The LDRA tool suite V 7.6.0 can detect violations of this recommendation.

Fortify SCA Version 5.0 with CERT C Rule Pack can detect violations of this recommendation.

...

Tool	Version	Checker	Description
CodeSonar	Include Page CodeSonar_V CodeSonar_V	ALLOC.DF ALLOC.LEAK	Double free Leak
Compass/ROSE			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
Coverity	6.5	RESOURCE_LEAK	Fully implemented
Klocwork	Include Page Klocwork_V Klocwork_V	FREE.INCONSISTENT UFM.FFM.MIGHT UFM.FFM.MUST UFM.DEREF.MIGHT UFM.DEREF.MUST UFM.RETURN.MIGHT UFM.RETURN.MUST UFM.USE.MIGHT UFM.USE.MUST MLK.MIGHT MLK.MUST MLK.RET.MIGHT MLK.RET.MUST FNH.MIGHT FNH.MUST FUM.GEN.MIGHT FUM.GEN.MUST RH.LEAK
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-MEM00-a CERT_C-MEM00-b CERT_C-MEM00-c CERT_C-MEM00-d CERT_C-MEM00-e	Do not allocate memory and expect that someone else will deallocate it later Do not allocate memory and expect that someone else will deallocate it later Do not allocate memory and expect that someone else will deallocate it later Do not use resources that have been freed Ensure resources are freed
Parasoft Insure++			Runtime analysis
PC-lint Plus	Include Page PC-lint Plus_V PC-lint Plus_V	449, 2434	Partially supported
Polyspace Bug Finder	Include Page Polyspace Bug Finder_V Polyspace Bug Finder_V	CERT C: Rec. MEM00-C	Checks for: Invalid free of pointer Deallocation of previously deallocated pointer Use of previously freed pointer Rec. partially covered.

Related Vulnerabilities

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

Other Languages

...

Related Guidelines

...

...

...

...

References

...

Bibliography

...

Image Added Image Added 9899:1999|AA. References#ISO/IEC 9899-1999]\] Section 7.20.3, "Memory Management Functions" \[[ISO/IEC PDTR 24772|AA. References#ISO/IEC PDTR 24772]\] "XYL Memory Leak" \[[MIT 04|AA. References#MIT 04]\] \[[MITRE 07|AA. References#MITRE 07]\] [CWE ID 416|http://cwe.mitre.org/data/definitions/416.html], "Use After Free," and [CWE ID 415|http://cwe.mitre.org/data/definitions/415.html], "Double Free" \[[Plakosh 05|AA. References#Plakosh 05]\] \[[Seacord 05a|AA. References#Seacord 05]\] Chapter 4, "Dynamic Memory Management"08. Memory Management (MEM)      08. Memory Management (MEM)      Image Modified