Use-After-Free in C: Why It Happens, How Static Analyzers Catch It, and What Rust Does Differently
Introduction: Why Use-After-Free Doesn't Always Crash
Memory is a crucial topic when it comes to building software. Programs running on historical devices referenced physical memory locations directly, a practice superseded by a dedicated hardware component: the Memory Management Unit (MMU). We now work with virtual memory addresses that is managed by MMU for us[0]. For a hands-on exploration of how process memory is laid out on macOS ARM64, see the memory post.
malloc and free: Why Accessing Freed Memory Can Silently Succeed
I recently stumbled across a video regarding the RustTM language. The intent of this post is not to look down on the RustTM language but to observe a behaviour of a trivial C program. A program fragment was shown in the video, similar to the one shown in Listing 1. After building the executable, we can notice that the program exits normally. But before that, we tried to access a region of memory that was "freed". In contrast, RustTM informs this issue during compilation.