Preventing Memory Errors: Double-Free and Use-After-Free

The Dangling Pointer: A Ticking Time Bomb

A use-after-free (UAF) error occurs when a program attempts to access memory through a pointer after that memory has been deallocated. This is a form of undefined behavior, and the consequences can range from a clean crash to silent, catastrophic data corruption.

The sequence of a UAF error is straightforward:

1. Memory is allocated on the heap, and a pointer (ptr) stores its address.
2. The program finishes using the memory and calls free(ptr). The memory is returned to the heap manager, but ptr still holds the address—it is now a dangling pointer.
3. Later, the program mistakenly dereferences this dangling pointer to read or write data.

Let's start by reading a clear definition of this vulnerability.

The danger lies in what happens between steps 2 and 3. The heap manager, now considering that memory block free, might re-allocate it for a completely different purpose. The dangling pointer then points to what seems like valid memory, but it contains entirely unrelated data.

This diagram illustrates the scenario perfectly:

From Bug to Exploit: The Severity of UAF

To truly appreciate the danger, it helps to see how a use-after-free vulnerability can be exploited. In your work on ADAS and gateway systems, you handle complex data structures and communication protocols where such a bug could allow malicious data to overwrite critical system state.

The following video from LiveOverflow, a channel focused on computer security and exploitation, provides a fantastic deep dive into a UAF scenario. It's more complex than a simple example, but given your background, you'll find the step-by-step debugging insightful. It demonstrates how reallocating freed memory with controlled data can lead to unauthorized access.

This demonstration should make it clear why UAF is classified as a severe security vulnerability. It breaks the conceptual boundary between different data objects in your program.

Preventing Use-After-Free: A Simple, Powerful Discipline

The primary cause of UAF is the existence of a dangling pointer. The solution, therefore, is to eliminate it.

The best practice is to set a pointer to NULL immediately after the memory it points to is freed.

free(ptr);
ptr = NULL; // Eliminates the dangling pointer

Why is this so effective?

• It destroys the dangling pointer. The ptr variable no longer holds the address of the deallocated memory.
• It turns a subtle UAF bug into an obvious, immediate crash. On most modern systems, attempting to dereference a NULL pointer (*ptr when ptr is NULL) results in a segmentation fault, stopping the program instantly. This is far preferable to silent data corruption, which can be incredibly difficult to debug.

The following video provides a clear walkthrough of this prevention technique.

The Double-Free Error

A closely related and equally dangerous error is the double-free. This occurs when free() is called more than once on the same memory address without an intervening allocation.

int *p = (int*)malloc(sizeof(int));
// ...
free(p);
// ... more code ...
free(p); // DOUBLE-FREE! Undefined behavior.

Why is this a problem? The heap manager maintains internal data structures, often a linked list, to keep track of free memory blocks. When you free(p), the block p points to is added to this free list. If you call free(p) again, the heap manager might try to add the same block to the list a second time. This can corrupt the free list's pointers, leading to bizarre crashes or security holes during subsequent malloc() calls.

Prevention: The solution to double-free is the exact same as for use-after-free: set the pointer to NULL after freeing it.

int *p = (int*)malloc(sizeof(int));
// ...
free(p);
p = NULL; // p is now NULL
// ... more code ...
free(p); // This is safe! free(NULL) does nothing.

The C standard guarantees that free(NULL) is a safe, valid operation that does nothing. By nullifying the pointer after the first free, you make any subsequent accidental free calls on that same pointer harmless.

#include <stdlib.h>
#include <stdio.h>

char *g_resource_buffer = NULL;

void initialize_resource() {
    if (g_resource_buffer == NULL) {
        g_resource_buffer = (char*)malloc(100);
        printf("Resource initialized.\n");
    }
}

void release_resource() {
    if (g_resource_buffer != NULL) {
        printf("Releasing resource...\n");
        free(g_resource_buffer);
        // A bug is here!
    }
}

void use_resource() {
    if (g_resource_buffer != NULL) {
        // Simulate using the resource
        g_resource_buffer[0] = 'A';
        printf("Resource used.\n");
    } else {
        printf("Cannot use released resource!\n");
    }
}

int main() {
    initialize_resource();
    use_resource();
    release_resource();
    
    // Some other part of the program accidentally releases it again
    printf("Attempting second release...\n");
    release_resource();
    
    // Later, an attempt to use the resource
    printf("Attempting to use after release...\n");
    use_resource();
    
    return 0;
}

The Automotive and Safety-Critical Perspective

Given your work with AUTOSAR, ISO 26262, and MISRA C, you might be thinking that these dynamic memory issues seem too risky for safety-critical code. You are absolutely correct.

The surest way to prevent dynamic memory errors is to not use dynamic memory at all. This is the approach taken by high-integrity coding standards.

By forbidding malloc, calloc, realloc, and free, MISRA C eliminates the possibility of memory leaks, use-after-free, double-free, and heap fragmentation. In systems where predictability and provable correctness are paramount (like an airbag controller or braking system), all memory is allocated statically at compile time. While this may seem restrictive, it's a necessary trade-off for achieving the highest levels of functional safety.

Conclusion

Today, you've confronted some of the most dangerous bugs in C programming. These errors are subtle, have non-deterministic effects, and are a source of major security vulnerabilities. Mastering their prevention is a mark of a proficient C developer.

Key Takeaways:

• A dangling pointer points to memory that has been deallocated.
• Use-after-free is dereferencing a dangling pointer. This can cause crashes or, worse, silent data corruption and security exploits.
• Double-free is calling free() twice on the same pointer. This corrupts the heap manager's internal state.
• The single most effective prevention strategy for both errors is to set a pointer to NULL immediately after freeing it: free(ptr); ptr = NULL;.
• In the highest-integrity systems, dynamic memory is often banned entirely to eliminate this class of errors, a rule codified in standards like MISRA C.

Preview of the Next Lesson:
We have now covered the complete lifecycle of dynamic memory: allocation, resizing, and the pitfalls of deallocation. In the next lesson, we will put this knowledge to practical use. You will implement a dynamic array data structure using malloc() and realloc(). This will require you to manage memory correctly across growth, shrinkage, and final destruction of the data structure, reinforcing all the concepts we've covered.