CWE-762 applies when the product tries to return a memory resource to the system, but calls a release function that is not compatible with the one that allocated it. Allocation and release come in pairs, and the pair has to match.
MITRE lists C and C++ on memory unsafe platforms. Large legacy codebases and code that mixes C and C++ conventions are where it turns up.
How it happens
MITRE describes two broad shapes.
- Stack memory freed as heap memory. The buffer was allocated automatically on the stack, then released with free(), which is meant only for explicitly allocated heap memory. This variant has its own entry, CWE-590.
- One family allocates, another releases. For example, memory allocated with malloc() in C++ instead of the new operator, then released with delete.
// Vulnerable: array form allocated, wrong release used
int *a = new int[16];
free(a); // mismatch: new[] must pair with delete[]
char buf[64];
free(buf); // stack memory handed to the heap allocator
The effect depends on the implementation of the routines and the object being managed, so a mismatch may appear to work on one platform and fail on another.
What an attacker gains
MITRE's consequences are memory modification, crash, exit or restart, and execution of unauthorized code or commands, touching integrity, availability and confidentiality. Severity and exploitability vary by implementation. At minimum, an attacker who can reach the faulty path can crash the program. At worst, corrupted allocator state is steered toward code execution.
The record has no observed CVE for this entry, so treat the general class description as the guide.
How to find it
MITRE recommends dynamic tools that add runtime memory checks at compile time, such as AddressSanitizer for C and C++ or valgrind. Both report an allocation and release function mismatch, as ASan does for new against free. A caveat from the record: crafted inputs are needed to reach the code that contains the problem, so tests and fuzzing need to exercise error and rare paths.
Code review has a straightforward rule. For every allocation, find its release, and confirm they belong to the same family: malloc with free, new with delete, new[] with delete[].
How to fix it
- Only call matching routines. Do not mix and match. If you allocate with malloc(), dispose of the original pointer with free().
- Use tools that manage memory for you. MITRE suggests languages or tools with automatic memory management, such as Automatic Reference Counting in Xcode for OS X and iOS targets. In C++ it recommends smart pointers: std::unique_ptr, std::shared_ptr, or equivalents such as Boost.
- Use a vetted library or framework that blocks the weakness. MITRE notes glibc on Linux protects against freeing invalid pointers.
- Choose a language with allocation abstractions where the project allows it.
// Fix: ownership expressed in the type, release always matches
auto a = std::make_unique<int[]>(16); // released with delete[] automatically
std::array<char, 64> buf; // stack storage, never freed by hand
Quick check
Why can a mismatch appear to work in testing?
Behavior depends on how the allocator implements each routine. Some platforms tolerate it while others corrupt memory, so passing tests prove little.
What is the simplest way to rule this out in C++?
Let smart pointers and containers own the memory so you never write a release call by hand.
Which tools find mismatches at runtime?
AddressSanitizer and valgrind, as named by MITRE, given inputs that reach the faulty code.
