Use After Free
Referencing memory after it has been freed can cause a program to crash, use unexpected values, or execute code.
The use of previously-freed memory can have any number of adverse consequences, ranging from the corruption of valid data to the execution of arbitrary code, depending on the instantiation and timing of the flaw. The simplest way data corruption may occur involves the system's reuse of the freed memory. Use-after-free errors have two common and sometimes overlapping causes:
Error conditions and other exceptional circumstances.
Confusion over which part of the program is responsible for freeing the memory.
In this scenario, the memory in question is allocated to another pointer validly at some point after it has been freed. The original pointer to the freed memory is used again and points to somewhere within the new allocation. As the data is changed, it corrupts the validly used memory; this induces undefined behavior in the process.
If the newly allocated data chances to hold a class, in C++ for example, various function pointers may be scattered within the heap data. If one of these function pointers is overwritten with an address to valid shellcode, execution of arbitrary code can be achieved.
The following examples help to illustrate the nature of this weakness and describe methods or techniques which can be used to mitigate the risk.
Note that the examples here are by no means exhaustive and any given weakness may have many subtle varieties, each of which may require different detection methods or runtime controls.
The following example demonstrates the weakness.
The following code illustrates a use after free error:
When an error occurs, the pointer is immediately freed. However, this pointer is later incorrectly used in the logError function.
Weaknesses in this category are related to the rules and recommendations in the Memory Management (MEM) section of the SEI CERT C Coding Standard.
This category identifies Software Fault Patterns (SFPs) within the Faulty Pointer Use cluster (SFP7).
Weaknesses in this category are related to rules in the Memory Management (MEM) section of the CERT C++ Secure Coding Standard. Since not all rules map to specific wea...
This view (slice) covers all the elements in CWE.
CWE entries in this view are listed in the 2020 CWE Top 25 Most Dangerous Software Weaknesses.
CWE entries in this view are listed in the 2021 CWE Top 25 Most Dangerous Software Weaknesses.