Common Weakness Enumeration

A Community-Developed Dictionary of Software Weakness Types

CWE/SANS Top 25 Most Dangerous Software Errors Common Weakness Scoring System
Common Weakness Risk Analysis Framework
Home > CWE List > CWE- Individual Dictionary Definition (2.7)  

Presentation Filter:

CWE-401: Improper Release of Memory Before Removing Last Reference ('Memory Leak')

Improper Release of Memory Before Removing Last Reference ('Memory Leak')
Weakness ID: 401 (Weakness Base)Status: Draft
+ Description

Description Summary

The software does not sufficiently track and release allocated memory after it has been used, which slowly consumes remaining memory.

Extended Description

This is often triggered by improper handling of malformed data or unexpectedly interrupted sessions.

+ Alternate Terms
Memory Leak
+ Terminology Notes

"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).

+ Time of Introduction
  • Architecture and Design
  • Implementation
+ Applicable Platforms




+ Modes of Introduction

Memory leaks have two common and sometimes overlapping causes:

  • Error conditions and other exceptional circumstances

  • Confusion over which part of the program is responsible for freeing the memory

+ Common Consequences

Technical Impact: DoS: crash / exit / 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.

+ Likelihood of Exploit


+ Demonstrative Examples

Example 1

The following C function leaks a block of allocated memory if the call to read() does not return the expected number of bytes:

(Bad Code)
Example Language:
char* getBlock(int fd) {
char* buf = (char*) malloc(BLOCK_SIZE);
if (!buf) {
return NULL;
if (read(fd, buf, BLOCK_SIZE) != BLOCK_SIZE) {

return NULL;
return buf;

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.

(Bad Code)
Example Language:
bar connection(){
foo = malloc(1024);
return foo;
endConnection(bar foo) {

int main() {

while(1) //thread 1
//On a connection
foo=connection(); //thread 2
//When the connection ends
+ Observed Examples
Memory leak because function does not free() an element of a data structure.
Memory leak when counter variable is not decremented.
chain: reference count is not decremented, leading to memory leak in OS by sending ICMP packets.
Kernel uses wrong function to release a data structure, preventing data from being properly tracked by other code.
Memory leak via unknown manipulations as part of protocol test suite.
Memory leak via a series of the same command.
+ Potential Mitigations

Phase: Implementation

Strategy: Libraries or Frameworks

Choose a language or tool that provides automatic memory management, or makes manual memory management less error-prone.

For example, glibc in Linux provides protection against free of invalid pointers.

When using Xcode to target OS X or iOS, enable automatic reference counting (ARC) [R.401.2].

To help correctly and consistently manage memory when programming in C++, consider using a smart pointer class such as std::auto_ptr (defined by ISO/IEC ISO/IEC 14882:2003), std::shared_ptr and std::unique_ptr (specified by an upcoming revision of the C++ standard, informally referred to as C++ 1x), or equivalent solutions such as Boost.

Phase: Architecture and Design

Use an abstraction library to abstract away risky APIs. Not a complete solution.

Phases: Architecture and Design; Build and Compilation

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.

+ Relationships
NatureTypeIDNameView(s) this relationship pertains toView(s)
ChildOfWeakness ClassWeakness Class398Indicator of Poor Code Quality
Seven Pernicious Kingdoms (primary)700
ChildOfCategoryCategory399Resource Management Errors
Development Concepts (primary)699
ChildOfCategoryCategory633Weaknesses that Affect Memory
Resource-specific Weaknesses (primary)631
ChildOfCategoryCategory730OWASP Top Ten 2004 Category A9 - Denial of Service
Weaknesses in OWASP Top Ten (2004) (primary)711
ChildOfWeakness BaseWeakness Base772Missing Release of Resource after Effective Lifetime
Research Concepts (primary)1000
ChildOfCategoryCategory861CERT Java Secure Coding Section 49 - Miscellaneous (MSC)
Weaknesses Addressed by the CERT Java Secure Coding Standard (primary)844
ChildOfCategoryCategory892SFP Cluster: Resource Management
Software Fault Pattern (SFP) Clusters (primary)888
MemberOfViewView630Weaknesses Examined by SAMATE
Weaknesses Examined by SAMATE (primary)630
CanFollowWeakness ClassWeakness Class390Detection of Error Condition Without Action
Research Concepts1000
+ Relationship Notes

This is often a resultant weakness due to improper handling of malformed data or early termination of sessions.

+ Affected Resources
  • Memory
+ Functional Areas
  • Memory management
+ Taxonomy Mappings
Mapped Taxonomy NameNode IDFitMapped Node Name
PLOVERMemory leak
7 Pernicious KingdomsMemory Leak
CLASPFailure to deallocate data
OWASP Top Ten 2004A9Denial of Service
CERT Java Secure CodingMSC04-JDo not leak memory
+ White Box Definitions

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

+ References
[R.401.1] J. Whittaker and H. Thompson. "How to Break Software Security". Addison Wesley. 2003.
[R.401.2] [REF-36] iOS Developer Library. "Transitioning to ARC Release Notes". 2013-08-08. <>.
+ Content History
Submission DateSubmitterOrganizationSource
Externally Mined
Modification DateModifierOrganizationSource
updated Time_of_Introduction
2008-08-01KDM AnalyticsExternal
added/updated white box definitions
Suggested OWASP Top Ten 2004 mapping
updated Applicable_Platforms, Common_Consequences, Relationships, Other_Notes, References, Relationship_Notes, Taxonomy_Mappings, Terminology_Notes
updated Description
updated Other_Notes
updated Name
Improved the White_Box_Definition
updated White_Box_Definitions
updated Modes_of_Introduction, Other_Notes
updated Relationships
updated Other_Notes, Potential_Mitigations
updated Demonstrative_Examples, Name
updated Alternate_Terms
updated Common_Consequences, Relationships, Taxonomy_Mappings
updated Relationships, Taxonomy_Mappings
updated Potential_Mitigations
updated Observed_Examples
updated Potential_Mitigations, References
Previous Entry Names
Change DatePrevious Entry Name
2008-04-11Memory Leak
2009-05-27Failure to Release Memory Before Removing Last Reference (aka 'Memory Leak')
2010-12-13Failure to Release Memory Before Removing Last Reference ('Memory Leak')
Page Last Updated: June 23, 2014