CWE-401: Missing Release of Memory after Effective Lifetime

Code Examples & CVEs

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:

BadC

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

Observed CVE Examples (6)

CVE-2005-3119

Memory leak because function does not free() an element of a data structure.

View Details

CVE-2004-0427

Memory leak when counter variable is not decremented.

View Details

CVE-2002-0574

chain: reference count is not decremented, leading to memory leak in OS by sending ICMP packets.

View Details

CVE-2005-3181

Kernel uses wrong function to release a data structure, preventing data from being properly tracked by other code.

View Details

CVE-2004-0222

Memory leak via unknown manipulations as part of protocol test suite.

View Details

CVE-2001-0136

Memory leak via a series of the same command.

View Details

Source-backed guidance

Additional facts reviewed against primary or authoritative security sources.

Prove every allocation has an owning release path

Match each dynamic allocation with a release before the lifetime of its final owning pointer ends, except for deliberately documented program-lifetime objects. Review early returns, error handling, ownership transfers, and reallocation paths for lost pointers. Use leak detection or static analysis and long-running tests to find memory growth that short functional tests may miss.

MEM31-C: Free dynamically allocated memory when no longer needed — Carnegie Mellon SEI

Make ownership and release automatic at every exit path

Represent ownership with scoped resource handles and RAII so release follows object lifetime automatically. Avoid naked owning pointers, pair acquisition with construction, transfer ownership explicitly, and keep cleanup safe during exceptions and early returns. For C or other manual environments, use one documented owner and a single cleanup path that covers partial initialization and failure.

C++ Core Guidelines: Resource Management — Standard C++ Foundation

Apply lessons from CVE-2023-26083 in Arm Mali GPU kernel driver

NVD maps CVE-2023-26083 to CWE-401; a missing-release condition in kernel-managed memory could let a non-privileged user expose sensitive kernel metadata through valid GPU operations. Use the case to verify cleanup after each GPU operation and error path, run repeated workloads while tracking retained kernel objects, and test whether unreleased state crosses security boundaries.

CVE-2023-26083 Detail — NIST National Vulnerability Database

Track CWE-401 as #23 in the 2024 CWE Top 25

CWE-401 ranked #23 in the 2024 CWE Top 25 with a score of 8.70. Use this annual evidence to prioritize systemic prevention, detection coverage, and recurring-root-cause metrics across the portfolio, while retaining asset exposure, exploitability, and business impact for severity decisions on individual findings.

2024 CWE Top 25 Most Dangerous Software Weaknesses — MITRE CWE

Measure retained allocations with Memcheck and long-running tests

Run unit and integration workloads under Memcheck, then compare definitely lost, indirectly lost, and still-reachable allocations against an approved baseline. Exercise repeated requests, failures, cancellation, reconnects, and partial initialization, and add soak tests that watch resident memory after load stops. Fix ownership rather than merely raising process limits or scheduling restarts.

Valgrind Memcheck Manual — Valgrind Developers

Frequently Asked Questions

What is CWE-401: Missing Release of Memory after Effective Lifetime?+

CWE-401: Missing Release of Memory after Effective Lifetime is a Common Weakness Enumeration (CWE) entry maintained by MITRE. The product does not sufficiently track and release allocated memory after it has been used, making the memory unavailable for reallocation and reuse.

Is CWE-401 in the CWE Top 25 Most Dangerous Software Weaknesses?+

Yes. CWE-401 ranked #23 in the CWE Top 25 for 2024, associated with 772 CVEs that year. The CWE Top 25 highlights the most common and impactful software weaknesses based on real-world vulnerability data.

What are the security consequences of Missing Release of Memory after Effective Lifetime?+

If exploited, CWE-401 (Missing Release of Memory after Effective Lifetime) it can compromise Availability and Other, leading to outcomes such as DoS: Crash, Exit, or Restart, DoS: Instability, DoS: Resource Consumption (CPU), DoS: Resource Consumption (Memory) and Reduce Performance.

How do you prevent or mitigate Missing Release of Memory after Effective Lifetime?+

Recommended mitigations for CWE-401 include: Use an abstraction library to abstract away risky APIs. Not a complete solution. Consider using the Boehm-Demers-Weiser garbage collector (bdwgc), which can help avoid leaks.

Which programming languages are affected by Missing Release of Memory after Effective Lifetime?+

CWE-401 commonly affects C, C++ and Not Language-Specific. Note that weaknesses are often language-agnostic patterns, so secure coding practices apply broadly.

What are real-world examples of Missing Release of Memory after Effective Lifetime?+

MITRE documents real CVEs mapped to CWE-401, including CVE-2005-3119, CVE-2004-0427, CVE-2002-0574, CVE-2005-3181 and CVE-2004-0222. You can look up the full details of each CVE, including CVSS scores and remediation guidance, on our CVE Lookup tool.

What is the difference between a CWE and a CVE?+

A CWE (Common Weakness Enumeration) like CWE-401 describes a category of software weakness — the underlying flaw type. A CVE (Common Vulnerabilities and Exposures) identifies a specific, real-world vulnerability in a particular product. In short, a CWE is the kind of mistake, and a CVE is an instance of that mistake being found in software.

CWE-401: Missing Release of Memory after Effective Lifetime

Technical Details

Applicable To

🏆 CWE Top 25 Historical Ranking

Security Consequences

Scope

Impact

Scope

Impact

Mitigation Strategies

Phase

Description

Phase

Description

Effectiveness

Detection Methods

Code Examples & CVEs

Demonstrative Examples

Observed CVE Examples (6)

CWE Relationships

Parent Weaknesses

Source-backed guidance

Prove every allocation has an owning release path

Make ownership and release automatic at every exit path

Apply lessons from CVE-2023-26083 in Arm Mali GPU kernel driver

Track CWE-401 as #23 in the 2024 CWE Top 25

Measure retained allocations with Memcheck and long-running tests

Frequently Asked Questions

Learn More