Do not evaluate any pointers into freed memory after an allocated block of dynamic storage has been deallocated by a memory management function, including dereferencing or acting as an operand of an arithmetic operation, type casting, or using the pointer as the right-hand side of an assignment. References to memory that has been deallocated are referred to as dangling pointers. Accessing a dangling pointer can result in exploitable vulnerabilities.
According to the C Standard, the behavior of a program that uses the value of a pointer that refers to space deallocated by a call to the free()
or realloc()
function is undefined. (See undefined behavior 177 of Annex J.)
Reading a pointer to deallocated memory is undefined behavior because the pointer value is indeterminate and can have a trap representation. In the latter case, doing so may cause a hardware trap.Accessing memory once it is freed may corrupt the data structures used to manage the heap. References to memory that has been deallocated are referred to as dangling pointers. Accessing a dangling pointer can result in exploitable vulnerabilities.
When memory is freed, its contents may remain intact and accessible because it is at the memory manager's discretion when to reallocate or recycle the freed chunk. The data at the freed location may appear valid. However, this can change unexpectedly, leading to unintended unexpected program behavior. As a result, it is necessary to guarantee that memory is not written to or read from once it is freed.
Writing to memory after it has been freed may corrupt the data structures used to manage the heap. Freeing memory multiple times has similar consequences to accessing memory after it is freed.
Noncompliant Code Example
...
Reading memory that has already been freed can lead to abnormal program termination and denial-of-service attacks. Writing memory that has already been freed can lead to the execution of arbitrary code with the permissions of the vulnerable process.
Freeing memory multiple times has similar consequences to accessing memory after it is freed. (See MEM30-C. Do not access freed memory.) First, reading a pointer to deallocated memory is undefined because the pointer value is indeterminate and can have a trap representation. In the latter case, doing so can cause a hardware trap. When reading a freed pointer doesn't cause a trap, the underlying data structures that manage the heap can become corrupted in a way that can introduce security vulnerabilities into a program. These types of issues are called double-free vulnerabilities. In practice, double-free vulnerabilities can be exploited to execute arbitrary code.
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 MEM04-C. Do not perform zero-length allocations.)
Rule | Severity | Likelihood | Remediation Cost | Priority | Level |
---|---|---|---|---|---|
MEM30-C | High | Likely | Medium | P18 | L1 |
...
Tool | Version | Checker | Description | ||||||
---|---|---|---|---|---|---|---|---|---|
|
|
| |||||||
| USE_AFTER_FREE | Can detect the specific instances where memory is deallocated more than once or read/written to the target of a freed pointer | |||||||
5.0 |
|
| |||||||
| UFM.DEREF.MIGHT |
| |||||||
| 51 D | Fully implemented | |||||||
|
|
|
Related Vulnerabilities
VU#623332 describes a double-free vulnerability in the MIT Kerberos 5 function krb5_recvauth().
Search for other vulnerabilities resulting from the violation of this rule on the CERT website.
...