| Wiki Markup |
|---|
Dynamic 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 05a2005a|AA. Bibliography#Seacord 05]\]. From the programmer's perspective, memory management involves allocating memory, reading and writing to memory, and deallocating memory. |
...
| Wiki Markup |
|---|
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.20.3 \[[ISO/IEC 9899:1999|AA. Bibliography#ISO/IEC 9899-1999]\]: |
...
| Wiki Markup |
|---|
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 042004|AA. Bibliography#MIT 04]\]. 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. |
...
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_size() 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.
...
Recommendation | Severity | Likelihood | Remediation Cost | Priority | Level |
|---|---|---|---|---|---|
MEM00-C | high | probable | medium | P12 | L1 |
Automated Detection
...
Tool | Version | Checker | Description |
|---|---|---|---|
|
...
|
|
| ||||||||
|
|
|
|
...
|
...
|
|
|
|
...
|
...
|
|
...
|
...
Related Vulnerabilities
Search for vulnerabilities resulting from the violation of this rule on the CERT website.
Other Languages
Related Guidelimes
This rule appears in the C++ Secure Coding Standard as : MEM40-CPP. Allocate and free memory in the same module, at the same level of abstraction.
Bibliography
| Wiki Markup |
|---|
\[[ISO/IEC 9899:1999|AA. Bibliography#ISO/IEC 9899-1999]\] Section 7.20.3, "Memory Management Functions" \[[ISO/IEC PDTR 24772|AA. Bibliography#ISO/IEC PDTR 24772]\] "XYL Memory Leak" \[[MIT 042004|AA. Bibliography#MIT 04]\] \[[MITRE 072007|AA. Bibliography#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 052005|AA. Bibliography#Plakosh 05]\] \[[Seacord 05a2005a|AA. Bibliography#Seacord 05]\] Chapter 4, "Dynamic Memory Management" |
...