CWE-763: Release of Invalid Pointer or Reference
Description
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.
- Abstraction
- BaseA weakness specific enough to point to detection and prevention methods.
- Likelihood of exploit
- Not rated by MITRE
- Status
- Incomplete
Common consequences
- IntegrityAvailabilityConfidentiality
Modify Memory; DoS: Crash, Exit, or Restart; Execute Unauthorized Code or Commands
This weakness may result in the corruption of memory, and perhaps instructions, possibly leading to a crash. If the corrupted memory can be effectively controlled, it may be possible to execute arbitrary code.
Potential mitigations
- 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
When programming in C++, consider using smart pointers provided by the boost library to help correctly and consistently manage memory.
- Architecture and DesignLibraries 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.
Related weaknesses
CAPEC attack patterns that exploit it
CWE 4.20 links no CAPEC attack pattern to this weakness.