Variant · Low-Medium

CWE-415: Double Free

The product calls free() twice on the same memory address.

CWE-415 · Variant Level ·8 CVEs ·3 Mitigations

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

The following code shows a simple example of a double free vulnerability.
Bad
char* ptr = (char*)malloc (SIZE);
				   ...
				   if (abrt) {
				   
					 free(ptr);
				   
				   }
				   ...
				   free(ptr);
Double free vulnerabilities have two common (and sometimes overlapping) causes:
Although some double free vulnerabilities are not much more complicated than this example, most are spread out across hundreds of lines of code or even different files. Programmers seem particularly susceptible to freeing global variables more than once.
While contrived, this code should be exploitable on Linux distributions that do not ship with heap-chunk check summing turned on.
Bad
#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

Architecture and Design

Choose a language that provides automatic memory management.

Implementation

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.

Implementation

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 IDDescription
CVE-2006-5051Chain: Signal handler contains too much functionality (CWE-828), introducing a race condition (CWE-362) that leads to a double free (CWE-415).
CVE-2004-0642Double free resultant from certain error conditions.
CVE-2004-0772Double free resultant from certain error conditions.
CVE-2005-1689Double free resultant from certain error conditions.
CVE-2003-0545Double free from invalid ASN.1 encoding.
CVE-2003-1048Double free from malformed GIF.
CVE-2005-0891Double free from malformed GIF.
CVE-2002-0059Double free from malformed compressed data.

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.