CWE-763 Detail

The product attempts to return a memory resource to the system, but it calls the wrong release function or calls the appropriate release function incorrectly.

This weakness can take several forms, such as:

• The memory was allocated, explicitly or implicitly, via one memory management method and deallocated using a different, non-compatible function (CWE-762).
• The function calls or memory management routines chosen are appropriate, however they are used incorrectly, such as in CWE-761.

Modes Of Introduction

Implementation

Common Consequences

Observed Examples

Potential Mitigations

Phases : 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().
Phases : Implementation
When programming in C++, consider using smart pointers provided by the boost library to help correctly and consistently manage memory.
Phases : Architecture and Design

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.

Phases : Architecture and Design
Use a language that provides abstractions for memory allocation and deallocation.
Phases : Testing
Use a tool that dynamically detects memory management problems, such as valgrind.

Detection Methods

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.
Effectiveness : High

Vulnerability Mapping Notes

Justification : This CWE entry is at the Base level of abstraction, which is a preferred level of abstraction for mapping to the root causes of vulnerabilities.
Comment : 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.

NotesNotes

The view-1000 subtree that is associated with this weakness needs additional work. Several entries will likely be created in this branch. Currently the focus is on free() of memory, but delete and other related release routines may require the creation of intermediate entries that are not specific to a particular function. In addition, the role of other types of invalid pointers, such as an expired pointer, i.e. CWE-415 Double Free and release of uninitialized pointers, related to CWE-457.

References

REF-657

boost C++ Library Smart Pointers
https://www.boost.org/doc/libs/1_38_0/libs/smart_ptr/smart_ptr.htm

REF-480

Valgrind
http://valgrind.org/

Submission

Modifications