...
To eliminate double-free vulnerabilities, it is necessary to guarantee that dynamic memory is freed exactly one time. Programmers should be wary when freeing memory in a loop or conditional statement; if coded incorrectly, these constructs can lead to double-free vulnerabilities. It is also a common error to misuse the realloc() function in a manner that results in double-free vulnerabilities. (See recommendation MEM04-C. Do not perform zero length allocations.)
The C99 standard says:
If memory for the new object cannot be allocated, the old object is not deallocated and its value is unchanged.
Some nonconforming implementations disagree with the standard when calling realloc() with size equal to 0. These implementations free the pointer that was passed as an argument and return a NULL pointer, so calling free() on the original pointer may be indeterminate.
Noncompliant Code Example
...
Tool | Version | Checker | Description |
|---|
| | | |
| | | |
| | | |
| | | | Section |
|---|
finds resource leaks from variables that go out of scope while owning a resource |
|
| | | | Section |
|---|
can find the instances where a freed memory is freed again. Coverity Prevent cannot discover all violations of this rule so further verification is necessary |
|
| | | | Section |
|---|
can detect some violations of this rule. In particular, false positives may be raised if a variable is freed by a different function than the one that allocated it. Also, it is unable to warn on cases where a call to free() happens inside of a for-loop |
|
| | | |
Related Vulnerabilities
...
