Description
The product calls free() twice on the same memory address.
Potential Impact
Integrity, Confidentiality, Availability
Modify Memory, Execute Unauthorized Code or Commands
Demonstrative Examples
char* ptr = (char*)malloc (SIZE);
...
if (abrt) {
free(ptr);
}
...
free(ptr);#include <stdio.h>#include <unistd.h>#define BUFSIZE1 512#define BUFSIZE2 ((BUFSIZE1/2) - 8)
int main(int argc, char **argv) {char *buf1R1;char *buf2R1;char *buf1R2;buf1R1 = (char *) malloc(BUFSIZE2);buf2R1 = (char *) malloc(BUFSIZE2);free(buf1R1);free(buf2R1);buf1R2 = (char *) malloc(BUFSIZE1);strncpy(buf1R2, argv[1], BUFSIZE1-1);free(buf2R1);free(buf1R2);}Mitigations & Prevention
Choose a language that provides automatic memory management.
Ensure that each allocation is freed only once. After freeing a chunk, set the pointer to NULL to ensure the pointer cannot be freed again. In complicated error conditions, be sure that clean-up routines respect the state of allocation properly. If the language is object oriented, ensure that object destructors delete each chunk of memory only once.
Use a static analysis tool to find double free instances.
Detection Methods
- Fuzzing High — Fuzz testing (fuzzing) is a powerful technique for generating large numbers of diverse inputs - either randomly or algorithmically - and dynamically invoking the code with those inputs. Even with random inputs, it is often capable of generating unexpected results such as crashes, memory corruption,
- Automated Static Analysis High — Automated static analysis, commonly referred to as Static Application Security Testing (SAST), can find some instances of this weakness by analyzing source code (or binary/compiled code) without having to execute it. Typically, this is done by building a model of data flow and control flow, then sea
- Automated Dynamic Analysis Moderate — Use tools that are integrated during compilation to insert runtime error-checking mechanisms related to memory safety errors, such as AddressSanitizer (ASan) for C/C++ [REF-1518].
Real-World CVE Examples
| CVE ID | Description |
|---|---|
| CVE-2006-5051 | Chain: Signal handler contains too much functionality (CWE-828), introducing a race condition (CWE-362) that leads to a double free (CWE-415). |
| CVE-2004-0642 | Double free resultant from certain error conditions. |
| CVE-2004-0772 | Double free resultant from certain error conditions. |
| CVE-2005-1689 | Double free resultant from certain error conditions. |
| CVE-2003-0545 | Double free from invalid ASN.1 encoding. |
| CVE-2003-1048 | Double free from malformed GIF. |
| CVE-2005-0891 | Double free from malformed GIF. |
| CVE-2002-0059 | Double free from malformed compressed data. |
Related Weaknesses
Taxonomy Mappings
- PLOVER: — DFREE - Double-Free Vulnerability
- 7 Pernicious Kingdoms: — Double Free
- CLASP: — Doubly freeing memory
- CERT C Secure Coding: MEM00-C — Allocate and free memory in the same module, at the same level of abstraction
- CERT C Secure Coding: MEM01-C — Store a new value in pointers immediately after free()
- CERT C Secure Coding: MEM30-C — Do not access freed memory
- CERT C Secure Coding: MEM31-C — Free dynamically allocated memory exactly once
- Software Fault Patterns: SFP12 — Faulty Memory Release
Frequently Asked Questions
What is CWE-415?
CWE-415 (Double Free) is a software weakness identified by MITRE's Common Weakness Enumeration. It is classified as a Variant-level weakness. The product calls free() twice on the same memory address.
How can CWE-415 be exploited?
Attackers can exploit CWE-415 (Double Free) to modify memory, execute unauthorized code or commands. This weakness is typically introduced during the Implementation phase of software development.
How do I prevent CWE-415?
Key mitigations include: Choose a language that provides automatic memory management.
What is the severity of CWE-415?
CWE-415 is classified as a Variant-level weakness (Low-Medium abstraction). It has been observed in 8 real-world CVEs.