Failure to Release Memory Before Removing Last Reference ('Memory Leak') |
Weakness ID: 401 (Weakness Base) | Status: Draft |
Description Summary
Extended Description
This is often triggered by improper handling of malformed data or unexpectedly interrupted sessions.
"memory leak" has sometimes been used to describe other kinds of issues, e.g. for information leaks in which the contents of memory are inadvertently leaked (CVE-2003-0400 is one such example of this terminology conflict). |
Memory leaks have two common and sometimes overlapping causes:
|
Scope | Effect |
---|---|
Availability | 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. |
Example 1
The following C function leaks a block of allocated memory if the call to read() fails to return the expected number of bytes:
Example 2
Here the problem is that every time a connection is made, more memory is allocated. So if one just opened up more and more connections, eventually the machine would run out of memory.
Reference | Description |
---|---|
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 | Memory leak when counter variable is not decremented. |
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. |
Pre-design: Use a language or compiler that performs automatic bounds checking. |
Phase: Architecture and Design Use an abstraction library to abstract away risky APIs. Not a complete solution. |
Pre-design through Build: 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. |
Nature | Type | ID | Name | View(s) this relationship pertains to![]() |
---|---|---|---|---|
ChildOf | ![]() | 398 | Indicator of Poor Code Quality | Seven Pernicious Kingdoms (primary)700 |
ChildOf | ![]() | 399 | Resource Management Errors | Development Concepts (primary)699 |
ChildOf | ![]() | 633 | Weaknesses that Affect Memory | Resource-specific Weaknesses (primary)631 |
ChildOf | ![]() | 730 | OWASP Top Ten 2004 Category A9 - Denial of Service | Weaknesses in OWASP Top Ten (2004) (primary)711 |
ChildOf | ![]() | 772 | Missing Release of Resource after Effective Lifetime | Research Concepts (primary)1000 |
MemberOf | ![]() | 630 | Weaknesses Examined by SAMATE | Weaknesses Examined by SAMATE (primary)630 |
CanFollow | ![]() | 390 | Detection of Error Condition Without Action | Research Concepts1000 |
This is often a resultant weakness due to improper handling of malformed data or early termination of sessions. |
Mapped Taxonomy Name | Node ID | Fit | Mapped Node Name |
---|---|---|---|
PLOVER | Memory leak | ||
7 Pernicious Kingdoms | Memory Leak | ||
CLASP | Failure to deallocate data | ||
OWASP Top Ten 2004 | A9 | CWE More Specific | Denial of Service |
A weakness where the code path has: 1. start statement that allocates dynamically allocated memory resource 2. end statement that loses identity of the dynamically allocated memory resource creating situation where dynamically allocated memory resource is never relinquished Where "loses" is defined through the following scenarios: 1. identity of the dynamic allocated memory resource never obtained 2. the statement assigns another value to the data element that stored the identity of the dynamically allocated memory resource and there are no aliases of that data element 3. identity of the dynamic allocated memory resource obtained but never passed on to function for memory resource release 4. the data element that stored the identity of the dynamically allocated resource has reached the end of its scope at the statement and there are no aliases of that data element |
Submissions | ||||
---|---|---|---|---|
Submission Date | Submitter | Organization | Source | |
PLOVER | Externally Mined | |||
Modifications | ||||
Modification Date | Modifier | Organization | Source | |
2008-07-01 | Eric Dalci | Cigital | External | |
updated Time of Introduction | ||||
2008-08-01 | KDM Analytics | External | ||
added/updated white box definitions | ||||
2008-08-15 | Veracode | External | ||
Suggested OWASP Top Ten 2004 mapping | ||||
2008-09-08 | CWE Content Team | MITRE | Internal | |
updated Applicable Platforms, Common Consequences, Relationships, Other Notes, References, Relationship Notes, Taxonomy Mappings, Terminology Notes | ||||
2008-10-14 | CWE Content Team | MITRE | Internal | |
updated Description | ||||
2009-03-10 | CWE Content Team | MITRE | Internal | |
updated Other Notes | ||||
2009-05-27 | CWE Content Team | MITRE | Internal | |
updated Name | ||||
2009-07-17 | KDM Analytics | External | ||
Improved the White Box Definition | ||||
2009-07-27 | CWE Content Team | MITRE | Internal | |
updated White Box Definitions | ||||
2009-10-29 | CWE Content Team | MITRE | Internal | |
updated Modes of Introduction, Other Notes | ||||
Previous Entry Names | ||||
Change Date | Previous Entry Name | |||
2008-04-11 | Memory Leak | |||
2009-05-27 | Failure to Release Memory Before Removing Last Reference (aka 'Memory Leak') | |||