Memory Safety
What is Memory Safety?
Memory SafetyMemory safety is the property that a program never reads, writes, or executes memory it has not legitimately allocated, preventing entire classes of vulnerabilities.
Memory safety guarantees include spatial safety (no out-of-bounds access), temporal safety (no use-after-free or double-free), type safety, and initialization safety. Languages like C and C++ are not memory safe by default, leading to most critical CVEs and exploits via buffer overflows, UAFs and type confusion. Modern industry data — including Microsoft, Google Project Zero, and the U.S. ONCD 2024 report — attributes 60-70 percent of high-severity vulnerabilities in major C/C++ code bases to memory-safety bugs. Mitigations (ASLR, DEP, CFI, sanitizers) raise the cost of exploitation, but eliminating the bugs at the source via memory-safe languages or formally verified subsets is the only definitive solution.
● Examples
- 01
An out-of-bounds write turning a heap chunk into an attacker-controlled object.
- 02
A use-after-free freeing a JavaScript object whose pointer is still held by a JIT cache.
● Frequently asked questions
What is Memory Safety?
Memory safety is the property that a program never reads, writes, or executes memory it has not legitimately allocated, preventing entire classes of vulnerabilities. It belongs to the Application Security category of cybersecurity.
What does Memory Safety mean?
Memory safety is the property that a program never reads, writes, or executes memory it has not legitimately allocated, preventing entire classes of vulnerabilities.
How does Memory Safety work?
Memory safety guarantees include spatial safety (no out-of-bounds access), temporal safety (no use-after-free or double-free), type safety, and initialization safety. Languages like C and C++ are not memory safe by default, leading to most critical CVEs and exploits via buffer overflows, UAFs and type confusion. Modern industry data — including Microsoft, Google Project Zero, and the U.S. ONCD 2024 report — attributes 60-70 percent of high-severity vulnerabilities in major C/C++ code bases to memory-safety bugs. Mitigations (ASLR, DEP, CFI, sanitizers) raise the cost of exploitation, but eliminating the bugs at the source via memory-safe languages or formally verified subsets is the only definitive solution.
How do you defend against Memory Safety?
Defences for Memory Safety typically combine technical controls and operational practices, as detailed in the full definition above.
What are other names for Memory Safety?
Common alternative names include: Memory-safety bugs.
● Related terms
- appsec№ 671
Memory-Safe Languages
Memory-safe languages such as Rust, Go, Swift, Java, and C# prevent the spatial and temporal memory errors that drive most exploitable vulnerabilities in C and C++.
- appsec№ 953
Rust Security Properties
Rust enforces memory and thread safety at compile time through ownership, borrowing, and lifetimes, eliminating common UB classes such as use-after-free and data races without a garbage collector.
- appsec№ 217
Control-Flow Integrity
Control-Flow Integrity (CFI) constrains a program's indirect calls and returns to a precomputed set of legitimate targets, blocking ROP and JOP exploits that hijack control flow.
- appsec№ 064
ASLR
Address Space Layout Randomization randomizes the memory locations of code, stacks, heaps, and libraries so attackers cannot reliably predict target addresses for exploits.
- appsec№ 303
DEP
Data Execution Prevention (also called NX or W^X) marks memory pages as non-executable so attackers cannot run shellcode injected into the stack or heap.
- appsec№ 925
Return-Oriented Programming
Return-Oriented Programming (ROP) is a code-reuse exploit technique that chains short instruction sequences ending in RET to execute arbitrary computation without injecting new code.
● See also
- № 1095Stack Canary
- № 1028Shadow Stack
- № 581KASLR
- № 1058SMEP / SMAP