How Rust Protects Against Memory Leaks and Memory Corruption

Memory safety is one of the most persistent challenges in programming. For decades, languages like C and C++ have given developers full control over memory management—but at the cost of security. Vulnerabilities like buffer overflows, use-after-free, and memory leaks have fueled countless exploits and real-world attacks.

Rust offers a new path forward. With its unique ownership model and borrow checker, Rust enforces memory safety at compile time, eliminating entire classes of bugs before code ever runs.

Performance and control 

When thinking about why Rust is a good alternative, it’s good to think about what we can’t afford to give up by switching from C or C++ – namely performance and control. Rust, just like C and C++ has a minimal and optional “runtime”. Rust’s standard library depends on libc for platforms that support it just like C and C++, but the standard library is also optional so running on platforms without an operating system is also possible.

Rust, just like C and C++, also gives the programmer fine-grained control on when and how much memory is allocated allowing the programmer to have a very good idea of exactly how the program will perform every time it is run. What this means for performance in terms of raw speed, control, and predictability, is that Rust, C, and C++ can be thought of in similar terms.

Ownership Model: No More Forgotten Frees

In C, developers must manually malloc() and free() memory. Forgetting free() causes a leak, double-free causes crashes or exploitation, and freeing too early creates dangling pointers attackers love to exploit.

Rust’s ownership model enforces a strict rule:

• Every piece of data has exactly one owner.

• When the owner goes out of scope, Rust automatically calls drop() and releases memory.

Example Code:

fn main() {
    let data = String::from("Hello, Rust!");
} // data is dropped here, memory freed automatically

Borrowing Rules: Preventing Conflicting Access

In C or C++, you can have multiple pointers (int* p1, int* p2) all pointing to the same memory. Nothing stops you from doing this:

int x = 10;
int* p1 = &x;
int* p2 = &x;

*p1 = 20;   // write through p1
*p2 = 30;   // write through p2
printf("%d\n", x); // what is x?

What’s the value of x at the end?

• Depends on the CPU timing, compiler optimization, and instruction order.

• Could be 20, 30, or even something unexpected due to reordering in optimized builds.

This is called undefined behavior.
Hackers exploit this kind of unpredictability for data corruption, race conditions, and privilege escalation.

Rust’s Borrowing Rules

Rust says:

• You can have many readers at the same time (& = immutable borrow).

• You can have only one writer at a time (&mut = mutable borrow).

• But you cannot mix them.

Why? Because this prevents the “two people writing to the same notebook at once” problem.

Visual Metaphor

• & (immutable reference) → readers in a library. Many people can read the same book, no issue.

• &mut (mutable reference) → writer editing the book. Only one writer allowed, because simultaneous edits = corruption.

• You cannot have readers + writer at the same time. Because what if a reader is looking at a page while the writer is tearing it out? That’s exactly the C problem.

Example in Rust:

fn main() {
    let mut data = 42;

    let r1 = &data;  // immutable borrow
    let r2 = &data;  // another immutable borrow
    println!("{}, {}", r1, r2); // works, multiple readers allowed

    let m = &mut data; // error: cannot borrow as mutable while immutable exists
    *m = 100;
}

Here the compiler refuses to compile because it sees:

• You already created r1 and r2 (readers).

• Then you tried to create m (writer).

• This could cause a race → so Rust stops you before the program even runs.

Lifetimes: Eliminating Use-After-Free

The use-after-free bug is an attacker’s best friend. If you can trick a program into accessing memory after it’s freed, you can often inject malicious payloads into that memory space.

Rust enforces lifetimes: every reference has to be provably valid while it’s in use.

fn dangling_ref() -> &String {
    let s = String::from("data");
    &s //  error: s does not live long enough
}

The compiler knows s is destroyed at function exit, so it forbids returning a reference.

• In C: attacker could reclaim freed memory with crafted input → arbitrary code execution.

• In Rust: the compiler rejects the program at build time.

Goodbye Null Pointers

Null dereference in C/C++ → immediate crash or exploitable state (e.g., attackers map memory at address 0x0 in some older systems).

Rust removes null completely. Instead, it uses Option, which forces developers to handle “maybe exists, maybe not.”

fn find_item(items: &[i32], target: i32) -> Option {
    for (i, &val) in items.iter().enumerate() {
        if val == target {
            return Some(i);
        }
    }
    None
}

• In C: NULL pointer deref → crash or attacker maps memory at 0x0.

• In Rust: impossible, None must be handled explicitly.

Safety 

What separates Rust from C and C++ is its strong safety guarantees. Unless explicitly opted-out of through usage of the “unsafe” keyword, Rust is completely memory safe, meaning that the issues we illustrated in this post are impossible to express. In a future post, we’ll revisit those examples to see how Rust prevents those issues usually without adding any runtime overhead. As we’ve seen, roughly 70% of the security issues that the MSRC assigns a CVE to are memory safety issues. This means that if that software had been written in Rust, 70% of these security issues would most likely have been eliminated. And we’re not the only company to have reported such findings.

In systems programming, sometimes the programmer must perform operations that cannot be statically verified as safe. Rust gives the programmer the tools to wrap these operations in safe abstractions, meaning that what was once relegated to code comments or convention can be statically enforced by the Rust compiler. Furthermore, the memory-unsafe operations must be explicitly marked as such, dramatically reducing the surface area security professionals must scrutinize for memory safety vulnerabilities.

Rust as a new programming language for platform code

Android 12 introduced Rust as a platform language. Rust provides memory and thread safety at performance levels similar to C/C++. We expect Rust to be the preferred choice for most new native projects. However, rewriting all memory unsafe code, currently representing over 70% of the Android platform code, in Rust isn't feasible. Moving forward Rust will be complementary to memory safety tools.

Conclusion

Rust doesn’t just patch over memory safety issues—it redefines the rules of the game. By shifting safety checks into the compiler with ownership, borrowing, and lifetimes, it eliminates entire classes of vulnerabilities before the code ever runs.

For developers, this means building high-performance systems without living in fear of buffer overflows or dangling pointers. For hackers, it means many of the most reliable exploitation techniques simply don’t exist in Rust.

In a world where memory corruption remains the root cause of most critical CVEs, Rust isn’t just “a safer C++”—it’s a security model baked into the language itself.