Description
The software does not sufficiently track and release allocated memory after it has been used, which slowly consumes remaining memory.
This is often triggered by improper handling of malformed data or unexpectedly interrupted sessions. In some languages, developers are responsible for tracking memory allocation and releasing the memory. If there are no more pointers or references to the memory, then it can no longer be tracked and identified for release.
Modes of Introduction:
– Architecture and Design
Likelihood of Exploit: Medium
Related Weaknesses
Consequences
Availability: DoS: Crash, Exit, or Restart, DoS: Instability, DoS: Resource Consumption (CPU), DoS: Resource Consumption (Memory)
Most memory leaks result in general software reliability problems, but if an attacker can intentionally trigger a memory leak, the attacker might be able to launch a denial of service attack (by crashing or hanging the program) or take advantage of other unexpected program behavior resulting from a low memory condition.
Other: Reduce Performance
Potential Mitigations
Phase: Implementation
Description:
Phase: Architecture and Design
Description:
Use an abstraction library to abstract away risky APIs. Not a complete solution.
Phase: Architecture and Design, Build and Compilation
Description:
The Boehm-Demers-Weiser Garbage Collector or valgrind can be used to detect leaks in code.
This is not a complete solution as it is not 100% effective.
CVE References
- CVE-2005-3119
- Memory leak because function does not free() an element of a data structure.
- CVE-2004-0427
- Memory leak when counter variable is not decremented.
- CVE-2002-0574
- chain: reference count is not decremented, leading to memory leak in OS by sending ICMP packets.
- CVE-2005-3181
- Kernel uses wrong function to release a data structure, preventing data from being properly tracked by other code.
- CVE-2004-0222
- Memory leak via unknown manipulations as part of protocol test suite.
- CVE-2001-0136
- Memory leak via a series of the same command.