What mitigations reduce the risk of multiple releases of the same resource or handle?

Why duplicate release bugs happen

Multiple releases usually come from the same ownership failure in different forms: one code path releases an object, another path still believes it owns the same object, and cleanup logic runs twice. That can happen after early returns, retries, exception handling, or shared references that outlive the original owner. The practical question is not just “can this be freed twice?” but “can any path still act as though the resource is live after release?”

A clear ownership model matters because duplicate release defects are often really state-tracking defects. If ownership is ambiguous, one thread or error handler can invalidate the resource while another continues to use or release it. That is why the fix is usually to make release idempotent in effect, or to ensure only one code path can ever reach the release action with authority over the handle.

When the resource is shared across threads, the problem becomes a coordination issue as well as a lifecycle issue. A plain “check then free” sequence is unsafe unless the check and release are atomic from the point of view of competing threads. Reference counting, lock-based ownership transfer, or other synchronised handoff patterns reduce the chance that two callers observe the same object as releasable at the same time.

Controls that make release safe in practice

The most reliable mitigation is to assign one clear release point and make every other path delegate to it. That usually means the code that acquires the resource also records who will release it, and other code paths only signal that release should happen. After release, the handle or pointer should be cleared, invalidated, or moved to a sentinel state so later cleanup logic cannot repeat the action accidentally.

In concurrent code, the release decision needs protection. Synchronisation around the release path, atomic state transitions, or reference counting can prevent two actors from believing they are the last holder. If the design uses reference counting, the decrement-to-zero transition must be the only place where actual destruction occurs, and that transition must be safe under contention.

Cleanup logic deserves special attention because duplicate release bugs often hide in error paths rather than the main success path. Review exception handlers, destructor-like cleanup, finally blocks, and rollback code for situations where a resource might already have been handed off or already closed. A good code review asks whether every exit path knows the current ownership state before it attempts cleanup.

These patterns are easier to maintain when the code makes invalid states obvious. For example, setting a released handle to null, zero, or another unusable marker can turn later accidental use into a detectable failure instead of a silent repeat release. That does not replace proper ownership tracking, but it does reduce the blast radius when a bug slips through.

Where the bug shows up and how to harden against it

Duplicate release issues often appear after refactoring, when error handling is added around existing code, or when a resource is passed between layers that each assume they own cleanup. They also emerge when the same handle is stored in more than one structure without a single authoritative owner. The safest designs make ownership transfer explicit and avoid “shared by default” resource semantics unless the lifetime rules are carefully documented.

Testing should deliberately force the awkward cases: exceptions after acquisition, partial initialisation, cancellation, concurrent release attempts, and repeated cleanup calls. Those cases are where the ownership model usually breaks down. Static analysis and sanitiser-style tooling can also help by surfacing double-close, double-free, and use-after-release patterns before they reach production.

Risk and Threat Considerations

Duplicate release bugs are not just correctness issues, they can become security issues when the released object still has a meaningful security role, such as a live connection, credential handle, memory object, or privileged session state. The same flaw can produce denial of service, memory corruption, or a use-after-free condition if later code continues to act on the invalidated object.

Failure mechanism: A second cleanup path, racing thread, or stale reference reaches the same release operation after ownership has already moved or the object has already been freed. If the runtime does not enforce safe object state transitions, the duplicate release can corrupt state or expose attacker-controlled reuse of memory or handles.

Impact: The result can range from crashes and intermittent instability to exploitable memory safety failures or unintended release of security-sensitive resources. In concurrent or privileged code, the operational impact is often wider than the immediate bug because cleanup logic is frequently invoked during error recovery, where reliability and assurance are already reduced.

Practitioner Guidance

What to verify: Confirm that every resource has one authoritative owner, every handoff updates ownership state immediately, and every release path can prove the resource is still live before acting. If a path cannot make that proof cheaply and consistently, redesign the lifetime model rather than adding another conditional check.

Decision rule: If the code can be released from multiple places, treat the design as high risk unless the final release is synchronised or reference-counted and all non-final paths only invalidate state. If cleanup is shared across success and failure paths, make the release function safe to call once from the owning path, not reusable everywhere.

Practitioner takeaway: The strongest mitigation is not “be careful,” it is to make duplicate release structurally difficult by design, then back that design with state invalidation and concurrency-safe ownership rules.

Related resources from NHI Mgmt Group

• Guide: CWE Top 25 Guide
• How do developers prevent multiple releases of the same resource or handle?
• What causes multiple releases of the same resource or handle?
• Multiple Releases of Same Resource or Handle
• How should app teams reduce identity attack risk when multiple login methods can attach to the same account?