CWE-401: Missing Release of Memory after Effective Lifetime

Description

The product does not sufficiently track and release allocated memory after it has been used, making the memory unavailable for reallocation and reuse.

Potential Impact

Availability

DoS: Crash, Exit, or Restart, DoS: Instability, DoS: Resource Consumption (CPU), DoS: Resource Consumption (Memory)

Other

Reduce Performance

Demonstrative Examples

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

Bad

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;
                     }

Mitigations & Prevention

Implementation

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) [REF-391]. To help correctly and consistently manage memory when programming in C++, consider using a smart pointer class such as std::auto_ptr (defined by

Architecture and Design

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

Architecture and DesignBuild and Compilation Moderate

Consider using the Boehm-Demers-Weiser garbage collector (bdwgc), which can help avoid leaks.

Detection Methods

Fuzzing High — 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,
Automated Dynamic Analysis Moderate — Use tools that are integrated during compilation to insert runtime error-checking mechanisms related to memory safety errors, such as AddressSanitizer (ASan) for C/C++ [REF-1518] or valgrind [REF-480].
Automated Static Analysis High — Automated static analysis, commonly referred to as Static Application Security Testing (SAST), can find some instances of this weakness by analyzing source code (or binary/compiled code) without having to execute it. Typically, this is done by building a model of data flow and control flow, then sea

Real-World CVE Examples

CVE ID	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	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.

Taxonomy Mappings

PLOVER: — Memory leak
7 Pernicious Kingdoms: — Memory Leak
CLASP: — Failure to deallocate data
OWASP Top Ten 2004: A9 — Denial of Service
CERT C Secure Coding: MEM31-C — Free dynamically allocated memory when no longer needed
The CERT Oracle Secure Coding Standard for Java (2011): MSC04-J — Do not leak memory
Software Fault Patterns: SFP14 — Failure to Release Resource
OMG ASCPEM: ASCPEM-PRF-14 —

Frequently Asked Questions

What is CWE-401?

CWE-401 (Missing Release of Memory after Effective Lifetime) is a software weakness identified by MITRE's Common Weakness Enumeration. It is classified as a Variant-level weakness. The product does not sufficiently track and release allocated memory after it has been used, making the memory unavailable for reallocation and reuse.

How can CWE-401 be exploited?

Attackers can exploit CWE-401 (Missing Release of Memory after Effective Lifetime) to dos: crash, exit, or restart, dos: instability, dos: resource consumption (cpu), dos: resource consumption (memory). This weakness is typically introduced during the Implementation phase of software development.

How do I prevent CWE-401?

Key mitigations include: 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 fre

What is the severity of CWE-401?

CWE-401 is classified as a Variant-level weakness (Low-Medium abstraction). It has been observed in 6 real-world CVEs.