In this code, x is freed twice. What is the risk of this code? x = malloc(200); /* do something with x / free(x); / do something else */ free(x);
-
This is a double free vulnerability and must be fixed
-
The second call to free() will return an error
-
There might be compiler warnings, but the program will run fine
-
This is not a security issue
Double-free corrupts the heap allocator's internal state, potentially enabling arbitrary code execution. It is a serious security vulnerability. Option B is wrong (free() on already-freed memory crashes or corrupts, doesn't return error). Option C and D incorrectly downplay the risk.
Calling free() twice on the same pointer without an intervening malloc is a double-free vulnerability. The first free() releases the memory back to the heap allocator's free list; the second free() on the same (now-stale) pointer corrupts the allocator's internal bookkeeping (e.g., the free-list metadata), which can be exploited by an attacker to achieve arbitrary memory writes, heap corruption, or code execution — a well-known class of security bug (CWE-415). The second call does not reliably return an error (behavior is undefined and allocator-dependent), it's not merely a benign compiler-warning situation, and it is very much a recognized security issue, not something to ignore.