Memory Safety: The Bug Class the Industry Can’t Keep Ignoring

Buffer overflows were already a well-understood attack vector when Morris used one in 1988. Decades later, memory corruption bugs — buffer overflows, use-after-free errors, out-of-bounds reads and writes — still dominate the CVE databases of the largest software producers in the world. That persistence isn’t a mystery. It’s a structural consequence of building a trillion-dollar industry on top of languages that hand memory management entirely to the programmer.

The question is no longer whether this is a problem. It’s why it took so long to treat it as one, and what “solving it” actually looks like in practice.

What Memory Safety Means, Precisely

A memory-safe language or runtime guarantees that a program cannot read or write memory it doesn’t own, and that it cannot use memory after that memory has been freed. Those two properties — spatial safety and temporal safety — eliminate an entire category of bugs.

C and C++ offer neither by default. A pointer is just a number. You can do arithmetic on it, pass it anywhere, dereference it after the object it pointed to is gone, and the language will not stop you. The compiler might warn you; the sanitizers will catch it at runtime. But in a release build with no instrumentation, bad memory accesses fail silently, or worse, produce exploitable behavior.

Languages with garbage collection — Java, Go, Python, JavaScript — solve this by managing object lifetimes automatically. You give up some control over when memory is reclaimed, and you absorb the cost of a runtime. For a wide range of applications, that’s a fine tradeoff. For systems code — OS kernels, device drivers, network stacks, cryptographic implementations — it historically wasn’t considered acceptable.

That’s the niche where C has lived for fifty years, and where most serious memory safety vulnerabilities originate.

The Scale Is Hard to Dismiss

The statistic that surfaces constantly in security discussions is that roughly 70% of serious vulnerabilities in large, mature C/C++ codebases are caused by memory safety bugs. Microsoft’s security team published analysis along these lines for their own products. Google’s Android security team reported similar proportions. These aren’t fringe claims — they’re supported by years of CVE categorization from organizations that have strong incentive to understand where their bugs come from.

What makes this class of bug particularly damaging is its exploitation ceiling. A memory safety bug doesn’t just crash a program — it can give an attacker arbitrary code execution. That’s why buffer overflows and use-after-free vulnerabilities consistently show up in exploit chains for the most serious breaches. They’re the bugs that let attackers escape sandboxes, escalate privileges, and install persistent access.

The Solutions Landscape

The options for addressing memory safety aren’t new, but their political and engineering weight is shifting.

Memory-safe languages are the most direct path. For new code, writing in Rust gives you memory safety without a garbage collector — the ownership and borrowing system enforces safety at compile time, with zero runtime overhead in most cases. Rust has been accepted into the Linux kernel, used for components of Android, and adopted for infrastructure code at several major cloud providers. Go is a pragmatic choice where GC overhead is tolerable. The direction is clear for greenfield work.

Compiler sanitizers and hardware mitigations help with existing C/C++ code. AddressSanitizer and MemorySanitizer are standard tools for finding bugs before they ship, though they impose overhead that makes them impractical in production. ARM’s Memory Tagging Extension (MTE) offers a hardware-assisted approach that’s cheap enough for production use — it tags memory regions and pointers, catching mismatches at runtime.

Formal rewrites of critical subsystems in memory-safe languages are ongoing but slow. The sheer volume of C code in production is immense. The TLS libraries, the DNS resolvers, the codec implementations — many have been in use for decades and carry both technical debt and implicit institutional knowledge.

The Inertia Problem

What slowed adoption for so long wasn’t ignorance. Security researchers have known about these bugs forever. The barriers were practical: performance assumptions, the cost of rewriting working code, and the relative scarcity of developers with systems programming experience outside C/C++.

What’s changed is the pressure. Government agencies in the US and Europe have issued guidance explicitly calling out memory-unsafe languages as a risk class. The cost model has shifted — high-severity exploits in critical infrastructure now carry regulatory and reputational consequences that are harder to externalize.

The C codebase isn’t going away any time soon. But the default for new systems work is changing, and the industry is slowly accepting that “we’ve always done it this way” is not an engineering justification.