← Back to Blog

Why Your "Memory-Safe" Language Is Still Lying to You

· 5 min read
memory safety security Rust C++ vulnerabilities systems programming exploitation software engineering debugging compilers

Why Your "Memory-Safe" Language Is Still Lying to You

Let me tell you about the worst debugging session of my career.

We had a Go service that was corrupting its own heap. Not occasionally—consistently, reproducibly, in production, under exactly 847 concurrent connections. I'd been doing this work for fifteen years, and I was certain this was impossible. Go is memory-safe. That's the whole point. You can't just... write past the end of a slice in Go.

Except you can. And I did. And it cost us a weekend and three terabytes of corrupted data before I found it.

This experience shattered a mental model I didn't realize I'd been building: the idea that memory safety is a binary state. That your code is either "safe" or "vulnerable." That writing in Rust or Go or Java means you're protected from the class of bugs that haunted C/C++ codebases for decades.

The truth is messier. Memory safety is a spectrum, and most developers are operating on assumptions that don't survive contact with production traffic.

The Spectrum Nobody Talks About

When people say a language is "memory-safe," they usually mean it prevents the classic memory corruption bugs: use-after-free, buffer overflows, double-free, stack smashing. And it's true—these languages eliminate entire categories of vulnerabilities by design. You can't overflow a Rust vector the same way you can overflow a char* buffer.

But here's what the marketing doesn't tell you: memory safety doesn't mean logical safety. It doesn't mean your code can't corrupt data. It doesn't mean your assumptions about ownership, lifetimes, or aliasing are correct. It just means the language's runtime will stop you from making specific, well-understood mistakes.

It says nothing about:

  • Data races in concurrent code
  • Logic errors that produce invalid state
  • Integer overflows leading to buffer-sized miscalculations
  • Unsafe blocks (Rust) or unsafe code paths (Go)
  • FFI boundaries where you call into C libraries
  • GC pauses causing visible corruption in latency-sensitive systems

I keep a running list of CVEs from "memory-safe" languages. Let me give you the highlights:

Go (2023-2025):

  • Multiple race condition vulnerabilities in the standard library's HTTP/2 implementation
  • Integer overflow in encoding/json that could cause heap corruption under specific inputs
  • Use-after-free in crypto/tls during connection close handshake

Java (2024):

  • Deserialization bugs that allowed arbitrary memory reads
  • Reflection API abuse enabling privilege escalation
  • GC-related memory corruption in specific concurrent collector configurations

Rust (2023-2025):

  • unsafe code in widely-used crates (yes, even std) allowing arbitrary code execution
  • Send/Sync trait violations that bypassed the type system's safety guarantees
  • Memory leaks that weren't bugs in the traditional sense but caused OOM crashes under long-running workloads

The pattern isn't that these languages are bad. The pattern is that developers hear "memory safe" and stop thinking about memory.

What Actually Happened in That Go Service

Back to my debugging nightmare. The service was a message queue consumer. Under exactly 847 connections—never 846, never 848—it would start corrupting its internal state.

After two days of staring at heap dumps, I found it. The code looked like this:

func processMessages(msgs []Message) {
    // This is fine for small slices
    buffer := make([]byte, 1024)
    
    for i, msg := range msgs {
        // Here's the bug: we're reusing the same buffer
        // but sometimes msgs[i].Payload is larger than 1024
        n := copy(buffer, msg.Payload)
        
        // Something downstream expects buffer to be exactly n bytes
        // But on the 847th iteration, n exceeded our expectations
        // because of how the Go scheduler interleaved goroutines
        processNext(buffer[:n])
    }
}

This isn't a buffer overflow in the C sense. Go's copy will only copy what's available. But the logic of the code assumed that the caller had already validated message sizes, and under specific concurrency patterns, that validation was racing against message processing.

The result wasn't a segfault or a panic. It was silent data corruption. Messages were being processed with truncated payloads, but the downstream service didn't validate checksums because "Go is memory-safe." The corrupt data propagated for hours before we noticed.

The lesson: Memory safety protected us from crashing. It didn't protect us from producing wrong answers.

The Integer Overflow Problem Nobody Tests

Here's another one. I reviewed a security-critical Rust service last year that parsed binary protocols. The authors were extremely careful about memory safety—every access was bounds-checked, they used Result types obsessively, they had comprehensive tests.

But their length field calculations were wrong.

// This looks safe. It is safe. But it's wrong.
fn calculate_buffer_size(header: &Header) -> usize {
    // header.length is u32, but we're adding header.offset
    // which can also be u32
    let size = header.length as usize + header.offset as usize;
    
    // If both are close to max u32, this wraps
    // But usize on 64-bit won't overflow here...
    // unless you compiled for 32-bit targets
    // OR unless the calculated size exceeds your actual allocation
    size
}

The bug only manifested when both fields were near u32::MAX. In testing, they never hit those values. In production, under adversarial input, an attacker could craft packets that:

  1. Passed all safety checks
  2. Produced a size that was logically wrong
  3. Caused a buffer to be allocated too small
  4. Resulted in subsequent writes going past the intended bounds

Was this a memory safety vulnerability? Technically no. The Rust compiler didn't let us write past the allocation. But the semantic error had identical consequences: data corruption, potential information disclosure, possible code execution depending on what happened next.

The FFI Trap

If you write any "memory-safe" code long enough, you'll eventually call into a C library. Maybe it's a crypto primitive that doesn't have a pure-Rust implementation yet. Maybe it's a database driver. Maybe it's legacy code you haven't migrated.

At that FFI boundary, your memory safety guarantees evaporate.

I've seen systems compromised not through vulnerabilities in the "safe" language layer, but through malformed data passed into a C library that didn't expect certain inputs. The safe language validated everything. Then it called C::process(data). And C::process had a buffer overflow that the safe language's caller had no way to anticipate.

This is why Apple and Google are pushing for entire codebases to be written in memory-safe languages—not just the new code, not just the networking layer, but everything. The weak link determines the chain's strength.

What You Should Actually Do

None of this is an argument against using Rust, Go, Java, or whatever memory-safe language you're currently using. They're genuinely better than the alternatives for most systems work. But here's what I'd actually recommend:

1. Stop thinking "memory-safe" means "correct."
Safety guarantees protect against specific classes of bugs. They don't protect against logical errors, race conditions, or your own incorrect assumptions about your data model.

2. Test the boundaries of your inputs.
Fuzz your parsers. Test with maximum values. Test with values that overflow your calculations. The bugs I find most often in "safe" codebases are at the edges of the input domain, not in the happy path.

3. Audit your unsafe blocks (Rust) or CGO boundaries (Go).
These are where your safety guarantees end. Treat them like you're writing C again—because you are.

4. Add checksums and validation at service boundaries.
Don't assume the caller validated everything. Don't assume the previous service got it right. Trust but verify, and log when verification fails.

5. Treat your GC'd runtime's pause characteristics as a security concern.
Memory-safe languages often have garbage collectors that can pause your entire process. Under load, these pauses can cause timeouts that cascade into retry storms, connection exhaustion, and data inconsistency. I've seen this kill production systems. It's not a memory corruption bug, but it has identical failure modes.

The Uncomfortable Truth

We're in a transitional period where the industry is learning that memory safety matters. That's good. But we've replaced one simplistic mental model ("C is unsafe, avoid it") with another ("my language is safe, so I'm protected").

The real answer is harder: security is hard, systems are complex, and no abstraction layer fully protects you from understanding what your code actually does.

I've been doing this for fifteen years. I still read assembly when I have to. I still look at core dumps at 3 AM. I still find bugs in code that "shouldn't" have bugs.

Because at the end of the day, your CPU doesn't know what language you wrote in. It just executes instructions. And if those instructions produce wrong results, no compiler flag or runtime safety check will save you.

The systems that work are the ones where the engineers understand what's actually happening underneath. Not because they don't trust their tools, but because they know exactly what those tools guarantee—and what they don't.

So yes, use Rust. Use Go. Use whatever lets you move fast without crashing into the obvious pitfalls.

But never stop thinking about memory.