The product attempts to return a memory resource to the system, but it calls a release function that is not compatible with the function that was originally used to allocate that resource.

This weakness can be generally described as mismatching memory management routines, such as:

The memory was allocated on the stack (automatically), but it was deallocated using the memory management routine free() (CWE-590), which is intended for explicitly allocated heap memory.
The memory was allocated explicitly using one set of memory management functions, and deallocated using a different set. For example, memory might be allocated with malloc() in C++ instead of the new operator, and then deallocated with the delete operator.

When the memory management functions are mismatched, the consequences may be as severe as code execution, memory corruption, or program crash. Consequences and ease of exploit will vary depending on the implementation of the routines and the object being managed.

Primary

Resultant

Implementation

Low

Integrity
Availability
Confidentiality
Modify Memory
DoS: Crash, Exit, or Restart
Execute Unauthorized Code or Commands

Dynamic Analysis with Automated Results Interpretation
Use a tool that dynamically detects memory
management problems, such as valgrind.

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.

Implementation
Only call matching memory management functions. Do not mix and match routines. For example, when you allocate a buffer with malloc(), dispose of the original pointer with free().

Implementation
Libraries or Frameworks

Choose a language or tool that provides automatic memory management, or makes manual memory management less error-prone.
For example, glibc in Linux provides protection against free of invalid pointers.
When using Xcode to target OS X or iOS, enable automatic reference counting (ARC) [REF-391].
To help correctly and consistently manage memory when programming in C++, consider using a smart pointer class such as std::auto_ptr (defined by ISO/IEC ISO/IEC 14882:2003), std::shared_ptr and std::unique_ptr (specified by an upcoming revision of the C++ standard, informally referred to as C++ 1x), or equivalent solutions such as Boost.

Architecture and Design
Libraries or Frameworks

Use a vetted library or framework that does not allow this weakness to occur or provides constructs that make this weakness easier to avoid.
For example, glibc in Linux provides protection against free of invalid pointers.

Architecture and Design
Use a language that provides abstractions for memory allocation and deallocation.

This example allocates a BarObj object using the new operator in C++, however, the programmer then deallocates the object using free(), which may lead to unexpected behavior.

void foo(){
BarObj *ptr = new BarObj()
/* do some work with ptr here */

...
free(ptr);
}

Instead, the programmer should have either created the object with one of the malloc family functions, or else deleted the object with the delete operator.

void foo(){
BarObj *ptr = new BarObj()
/* do some work with ptr here */

...
delete ptr;
}

In this example, the program does not use matching functions such as malloc/free, new/delete, and new[]/delete[] to allocate/deallocate the resource.

class A {void foo();};void A::foo(){int *ptr;ptr = (int*)malloc(sizeof(int));delete ptr;}

In this example, the program calls the delete[] function on non-heap memory.

class A{void foo(bool);};void A::foo(bool heap) {int localArray[2] = {11,22};int *p = localArray;if (heap){p = new int[2];}delete[] p;}

Memory Management

Memory

WIN30-C
Properly pair allocation and deallocation functions
Exact

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 weakness is possible in any programming language that allows manual management of memory.

CWE Content Team
MITRE
2009-05-08
1.4
2009-05-27

CWE Content Team
MITRE
2009-12-28
updated Applicable_Platforms, Likelihood_of_Exploit

CWE Content Team
MITRE
2010-06-21
updated Description, Potential_Mitigations

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 Demonstrative_Examples, Relationships

CWE Content Team
MITRE
2012-10-30
updated Potential_Mitigations

CWE Content Team
MITRE
2014-02-18
updated Demonstrative_Examples, Potential_Mitigations, References

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

CWE Content Team
MITRE
2017-11-08
updated Applicable_Platforms, References, Taxonomy_Mappings

CWE Content Team
MITRE
2019-01-03
updated Relationships

CWE Content Team
MITRE
2020-02-24
updated Relationships

CWE Content Team
MITRE
2020-12-10
updated Relationships

CWE Content Team
MITRE
2021-03-15
updated Relationships

CWE Content Team
MITRE
2023-01-31
updated Description

CWE Content Team
MITRE
2023-04-27
updated References, Relationships

CWE Content Team
MITRE
2023-06-29
updated Mapping_Notes

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

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

Martin Sebor
Cisco Systems, Inc.
2010-04-30
Provided improvement to existing Mitigation