Allocating and freeing memory in different modules and levels of abstraction burdens the programmer with tracking the lifetime of that block of memory. This may cause confusion regarding when and if a block of memory has been allocated or freed, leading to programming defects such as double-free vulnerabilities, accessing freed memory, or writing to unallocated memory.
To avoid these situations, it is recommended that memory be allocated and freed at the same level of abstraction, and ideally in the same code module.
The affects of not following this recommendation are best demonstrated by an actual vulnerability. Freeing memory in different modules resulted in a vulnerability in MIT Kerberos 5 http://web.mit.edu/kerberos/advisories/MITKRB5-SA-2004-002-dblfree.txt. The problem is the MIT Kerberos 5 code contains error-handling logic, which frees memory allocated by the ASN.1 decoders if pointers to the allocated memory are non-null. However, if a detectable error occurs, the ASN.1 decoders themselves free memory that they have allocated. When some library functions receive errors from the ASN.1 decoders, they also attempt to free, causing a double-free vulnerability.
Non-Compliant Code Example 1
This example demonstrates an error that can occur when memory is freed in different functions. First, an array of integers is dynamically allocated. The array, which is referred to by list and its size, number, are then passed to func2. If the number of elements in the array is greater than the value MIN_SIZE_ALLOWED, the array is processed. Otherwise, it is assumed an error has occurred, list is freed, and the function returns. If the error occurs in func2, the dynamic memory referred to by list will be freed twice: once in func2 and again at the end of func1.
#define MIN_SIZE_ALLOWED 10
void func2(int *list, size_t list_size) {
if (size < MIN_SIZE_ALLOWED) {
/* Handle Error Condition */
free(list);
return;
}
/* Process list */
}
void func1 (size_t number) {
int *list = malloc (number * sizeof(int));
if (list == NULL) {
/* Handle Allocation Error */
}
func2(list,number);
/* Continue Processing list */
free(list);
}
Compliant Solution 1
To correct this problem, the logic in the error handling code should be changed so that it no longer frees list. This change ensures that list is freed only once, in func1.
#define MIN_SIZE_ALLOWED 10
void func2(int *list, size_t list_size) {
if (size < MIN_SIZE_ALLOWED) {
/* Handle Error Condition */
return;
}
/* Process list */
}
void func1 (size_t number) {
int *list = malloc (number * sizeof(int));
if (list == NULL) {
/* Handle Allocation Error */
}
func2(list,number);
/* Continue Processing list */
free(list);
}
References
- Seacord 05 Chapter 4, Dynamic Memory Management
- Consistent Memory Management Conventions, Dan Plakosh
- MIT Kerberos 5 Security Advisory 2004-002