This vulnerability occurs when a program incorrectly tries to close or release the same system resource—like memory, a file, or a network connection—more than once. This double-free or double-close violates the API's contract and leads to unpredictable and often dangerous behavior.
Modern software constantly acquires and releases resources such as memory blocks, file handles, and socket connections. APIs like `free()`, `delete()`, or `close()` are designed to manage this lifecycle, but they typically assume the developer will call them exactly once per resource. When the same release function is called a second time on an already-freed resource, the underlying system management structures can become corrupted. This corruption can directly cause crashes, memory leaks, or even create security gaps that attackers might exploit to execute arbitrary code. To prevent this, developers must carefully manage the state of each resource handle, ensuring release calls are paired one-to-one with successful acquisitions. A common best practice is to set pointers or handles to NULL (or another null-like state) immediately after release, as many safe implementations will check for this and ignore subsequent calls. Reusing the same variable identifier for a different resource before properly closing the first is a major risk, as it can lead to closing the wrong, active resource, compounding the problem.
Impact: DoS: Crash, Exit, or Restart
Strategy: Refactoring
Strategy: Refactoring
Effectiveness: Defense in Depth
char b[2000]; FILE *f = fopen("dbl_cls.c", "r"); if (f) {
cchar b[2000]; FILE *f = fopen("dbl_cls.c", "r"); if (f) {
cchar b[2000]; int f_flg = 0; FILE *f = fopen("dbl_cls.c", "r"); if (f) {
cc