What causes multiple releases of the same resource or handle?

Why multiple releases happen

Multiple releases of the same resource or handle usually point to a cleanup path that is not owned in one place. The common pattern is that normal flow and error flow both believe they are responsible for the same object, so the same free, close, or release call can run twice. Once that happens, the code is no longer describing a benign cleanup issue, it is describing a memory safety or resource integrity problem.

The root cause is often unclear ownership. One function allocates or acquires the handle, another stores it, and a third cleans it up after an error, but none of them has a single source of truth about who must release it. That is why the same weakness can appear as a double free, double close, invalid pointer release, or repeated cleanup of the same descriptor or reference.

Defensive code should make the ownership boundary explicit. A released handle should be set to an invalid value immediately, and cleanup paths should be written so they can run once without repeating the same release. In practice, that means a resource should have one owner at a time, and that owner should be the only code allowed to release it.

How cleanup logic becomes exploitable

Repeated release is dangerous because the second call is not harmless bookkeeping. In memory-managed code it can corrupt allocator state, reuse freed memory unexpectedly, or trigger a crash at a point far from the original bug. For file descriptors, sockets, locks, or other operating-system handles, the second release can invalidate the wrong object or make later code act on stale state.

The problem is amplified when exception handling or early returns duplicate cleanup logic. A fast failure path may free a handle before the normal exit path runs, and the second path then frees it again. That is why this weakness is often tied to incomplete cleanup, improper cleanup on thrown exception, unchecked error handling, or inconsistent state transitions after a failed operation.

For a memory-safety perspective on related weakness patterns, the CWE Top 25 Guide is useful because it places repeated release alongside adjacent software weakness classes such as invalid pointer release, incomplete cleanup, and release of resources during the wrong lifetime.

What good mitigation looks like in practice

The safest pattern is to make release idempotent at the design level, not by hoping every caller remembers the rule. Use a single cleanup owner, null or invalidate the reference after release, and prefer structured cleanup that cannot be entered twice for the same object. When a language or runtime supports it, wrap the resource in a guard, smart pointer, or scoped handle so ownership and release are coupled.

Reviewers should also look for the surrounding conditions that make repeat release likely: shared error labels, duplicated cleanup blocks, copy-pasted close logic, and functions that both borrow and own the same handle. If the codebase mixes manual cleanup with multiple exit points, the chance of a second release rises quickly. Simple local fixes help, but the long-term answer is to redesign ownership so release responsibility is obvious from the call graph.

Risk and Threat Considerations

Repeated release is a security issue when the object being released controls memory, execution state, or a privileged operating-system or application resource. A double release can destabilise the process, corrupt internal bookkeeping, or create a path to arbitrary memory misuse if an attacker can influence timing, object reuse, or the sequence of operations.

Failure mechanism: A second free, close, or release acts on stale state because the program never recorded that the resource was already released, or because two different error paths both believe they own the same object.

Impact: The immediate effect is often a crash, but the higher-value concern is memory corruption, undefined behaviour, or unintended reuse of a freed object, which can turn a coding defect into a reliable exploit primitive.

Practitioner Guidance

What to verify: Check whether every resource has exactly one release path in the normal flow and exactly one release path in the exceptional flow, with no overlap. If the same handle can be touched by multiple layers, verify that ownership is transferred explicitly and that all later references are treated as non-owning.

Common mistake: Treating “we already free on error” as sufficient. That is only safe if every other exit path is guaranteed to skip the same cleanup, and that guarantee is often weaker than the code suggests.

Practitioner takeaway: The key control is not adding more cleanup, it is preventing ambiguous ownership, because double release is usually a design problem first and a bug fix problem second.

Related resources from NHI Mgmt Group

• How do developers prevent multiple releases of the same resource or handle?
• Multiple Releases of Same Resource or Handle
• How should teams handle multiple licence findings in the same component?
• How should security teams handle encrypted metadata when multiple people and systems need to use the same credential across different applications?