Use After Free occurs when a program continues to reference memory that has already been freed and returned to the system. This can cause the application to…
Use After Free occurs when a program continues to reference memory that has already been freed and returned to the system. This can cause the application to crash, read corrupted data, or—if an attacker can control what gets allocated in that freed memory—execute arbitrary code. It is a memory safety issue most common in languages like C and C++ that require manual memory management.
A Use After Free vulnerability arises when code frees a block of memory but retains a pointer to it and later dereferences that pointer. Between the free and the reuse, the memory may be reallocated for a different purpose, overwritten, or left in an inconsistent state. The program may then read stale data, write to unintended locations, or trigger undefined behavior. This is particularly dangerous in long-running applications or those handling untrusted input, where the timing between free and reuse can be controlled or predicted by an attacker.
A Use After Free can lead to information disclosure if the freed memory is read before being overwritten—exposing sensitive data like encryption keys or session tokens. It can also cause denial of service through application crashes. In the worst case, if an attacker can influence what data is allocated in the freed memory region, they may be able to corrupt critical data structures or hijack control flow, leading to arbitrary code execution with the privileges of the affected process.
#include <stdlib.h>
#include <string.h>
typedef struct {
char *name;
int id;
} User;
void process_user(User *user) {
char *temp = user->name;
free(user->name);
user->name = NULL;
// Later in the function, use after free:
if (strlen(temp) > 0) { // temp points to freed memory
printf("User: %s\n", temp);
}
}Why it's vulnerable:
The pointer temp is not set to NULL after free(), and the code continues to dereference it. The memory it points to may have been reallocated or corrupted.
#include <stdlib.h>
#include <string.h>
typedef struct {
char *name;
int id;
} User;
void process_user(User *user) {
if (user->name != NULL) {
printf("User: %s\n", user->name);
}
free(user->name);
user->name = NULL; // Null out the pointer after freeing
}class Resource:
def __init__(self, data):
self.data = data
self.handle = id(self) # Simulate a resource handle
def cleanup(self):
del self.data
self.handle = None
resource = Resource([1, 2, 3])
resource.cleanup()
# Use after free: accessing deleted attribute
print(resource.data) # AttributeError, but in C/C++ this could be silent corruptionWhy it's vulnerable:
After cleanup() deletes the data, the code attempts to access it. In Python this raises an error, but in lower-level languages this would silently read garbage.
class Resource:
def __init__(self, data):
self.data = data
self.handle = id(self)
def cleanup(self):
self.data = None
self.handle = None
def use(self):
if self.data is not None:
return self.data
else:
raise ValueError("Resource has been cleaned up")
resource = Resource([1, 2, 3])
resource.cleanup()
result = resource.use() # Raises ValueError instead of accessing freed memorystd::unique_ptr, std::shared_ptr in C++), garbage collection, or memory-safe languages.
Unexplained application crashes, segmentation faults, or memory corruption errors in logs may indicate use-after-free bugs. If you observe inconsistent behavior, data corruption, or crashes that occur intermittently or under specific load conditions, memory safety issues should be investigated. Tools like AddressSanitizer or Valgrind can help confirm whether freed memory is being accessed.
