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

Resultant

Double-free

Implementation

High

Integrity
Confidentiality
Availability
Modify Memory
Execute Unauthorized Code or Commands
When a program calls free() twice with the same argument, the program's memory management data structures may become corrupted, potentially leading to the reading or modification of unexpected memory addresses. This corruption can cause the program to crash or, in some circumstances, cause two later calls to malloc() to return the same pointer. If malloc() returns the same value twice and the program later gives the attacker control over the data that is written into this doubly-allocated memory, the program becomes vulnerable to a buffer overflow attack.
Doubly freeing memory may result in a write-what-where condition, allowing an attacker to execute arbitrary code.

Fuzzing
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, or resource consumption. Fuzzing effectively produces repeatable test cases that clearly indicate bugs, which helps developers to diagnose the issues.
High

Automated Static Analysis
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 searching for potentially-vulnerable patterns that connect "sources" (origins of input) with "sinks" (destinations where the data interacts with external components, a lower layer such as the OS, etc.)
High

Automated Dynamic Analysis
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].
Moderate
Crafted inputs are necessary to
reach the code containing the error, such as generated
by fuzzers. Also, these tools may reduce performance,
and they only report the error condition - not the
original mistake that led to the
error.

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.

The following code shows a simple example of a double free vulnerability.

char* ptr = (char*)malloc (SIZE);
...
if (abrt) {

free(ptr);

}
...
free(ptr);

Double free vulnerabilities have two common (and sometimes overlapping) causes:

Error conditions and other exceptional circumstances

Confusion over which part of the program is responsible for freeing the memory

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.

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

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).
https://www.cve.org/CVERecord?id=CVE-2006-5051

CVE-2004-0642
Double free resultant from certain error conditions.
https://www.cve.org/CVERecord?id=CVE-2004-0642

CVE-2004-0772
Double free resultant from certain error conditions.
https://www.cve.org/CVERecord?id=CVE-2004-0772

CVE-2005-1689
Double free resultant from certain error conditions.
https://www.cve.org/CVERecord?id=CVE-2005-1689

CVE-2003-0545
Double free from invalid ASN.1 encoding.
https://www.cve.org/CVERecord?id=CVE-2003-0545

CVE-2003-1048
Double free from malformed GIF.
https://www.cve.org/CVERecord?id=CVE-2003-1048

CVE-2005-0891
Double free from malformed GIF.
https://www.cve.org/CVERecord?id=CVE-2005-0891

CVE-2002-0059
Double free from malformed compressed data.
https://www.cve.org/CVERecord?id=CVE-2002-0059

Memory Management

Memory

DFREE - Double-Free Vulnerability

Double Free

Doubly freeing memory

MEM00-C
Allocate and free memory in the same module, at the same level of abstraction

MEM01-C
Store a new value in pointers immediately after free()

MEM30-C
Do not access freed memory
CWE More Specific

MEM31-C
Free dynamically allocated memory exactly once

SFP12
Faulty Memory Release

Allowed
This CWE entry is at the Variant level of abstraction, which is a preferred level of abstraction for mapping to the root causes of vulnerabilities.
Carefully read both the name and description to ensure that this mapping is an appropriate fit. Do not try to 'force' a mapping to a lower-level Base/Variant simply to comply with this preferred level of abstraction.

This is usually resultant from another weakness, such as an unhandled error or race condition between threads. It could also be primary to weaknesses such as buffer overflows.
It could be argued that Double Free would be most appropriately located as a child of "Use after Free", but "Use" and "Release" are considered to be distinct operations within vulnerability theory, therefore this is more accurately "Release of a Resource after Expiration or Release", which doesn't exist yet.

PLOVER
2006-07-19
Draft 3
2006-07-19

Eric Dalci
Cigital
2008-07-01
updated Potential_Mitigations, Time_of_Introduction

KDM Analytics
2008-08-01
added/updated white box definitions

CWE Content Team
MITRE
2008-09-08
updated Applicable_Platforms, Common_Consequences, Description, Maintenance_Notes, Relationships, Other_Notes, Relationship_Notes, Taxonomy_Mappings

CWE Content Team
MITRE
2008-11-24
updated Relationships, Taxonomy_Mappings

CWE Content Team
MITRE
2009-05-27
updated Demonstrative_Examples

CWE Content Team
MITRE
2009-10-29
updated Other_Notes

CWE Content Team
MITRE
2010-09-27
updated Relationships

CWE Content Team
MITRE
2010-12-13
updated Observed_Examples, Relationships

CWE Content Team
MITRE
2011-06-01
updated Common_Consequences

CWE Content Team
MITRE
2011-09-13
updated Relationships, Taxonomy_Mappings

CWE Content Team
MITRE
2012-05-11
updated References, Relationships

CWE Content Team
MITRE
2014-07-30
updated Relationships, Taxonomy_Mappings

CWE Content Team
MITRE
2015-12-07
updated Relationships

CWE Content Team
MITRE
2017-11-08
updated Likelihood_of_Exploit, Relationships, Taxonomy_Mappings, White_Box_Definitions

CWE Content Team
MITRE
2019-01-03
updated Relationships

CWE Content Team
MITRE
2019-06-20
updated Relationships

CWE Content Team
MITRE
2020-02-24
updated References, Relationships

CWE Content Team
MITRE
2020-06-25
updated Common_Consequences

CWE Content Team
MITRE
2020-08-20
updated Relationships

CWE Content Team
MITRE
2020-12-10
updated Relationships

CWE Content Team
MITRE
2021-03-15
updated Maintenance_Notes, Theoretical_Notes

CWE Content Team
MITRE
2021-10-28
updated Relationships

CWE Content Team
MITRE
2022-04-28
updated Demonstrative_Examples, Observed_Examples

CWE Content Team
MITRE
2023-04-27
updated Detection_Factors, Relationships, Time_of_Introduction

CWE Content Team
MITRE
2023-06-29
updated Mapping_Notes

CWE Content Team
MITRE
2025-04-03
4.17
2025-04-03
updated Common_Consequences, Description, Diagram

CWE Content Team
MITRE
2025-09-09
4.18
2025-09-09
updated Functional_Areas

CWE Content Team
MITRE
2025-12-11
4.19
2025-12-11
updated Applicable_Platforms, Detection_Factors, References, Weakness_Ordinalities