Memory safety is the state of being protected from various software bugs and security vulnerabilities when dealing with memory access, such as buffer overflows and dangling pointers.[1] For example, Java is said to be memory-safe because its runtime error detection checks array bounds and pointer dereferences.[1] In contrast, C and C++ allow arbitrary pointer arithmetic with pointers implemented as direct memory addresses with no provision for bounds checking,[2] and thus are potentially memory-unsafe.[3]


Memory errors were first considered in the context of resource management and time-sharing systems, in an effort to avoid problems such as fork bombs.[4] Developments were mostly theoretical until the Morris worm, which exploited a buffer overflow in fingerd.[5] The field of computer security developed quickly thereafter, escalating with multitudes of new attacks such as the return-to-libc attack and defense techniques such as the non-executable stack[6] and address space layout randomization. Randomization prevents most buffer overflow attacks and requires the attacker to use heap spraying or other application-dependent methods to obtain addresses, although its adoption has been slow.[5] However, deployments of the technology are typically limited to randomizing libraries and the location of the stack.


DieHard,[7] its redesign DieHarder,[8] and the Allinea Distributed Debugging Tool are special heap allocators that allocate objects in their own random virtual memory page, allowing invalid reads and writes to be stopped and debugged at the exact instruction that causes them. Protection relies upon hardware memory protection and thus overhead is typically not substantial, although it can grow significantly if the program makes heavy use of allocation.[9] Randomization provides only probabilistic protection against memory errors, but can often be easily implemented in existing software by relinking the binary.

The memcheck tool of Valgrind uses an instruction set simulator and runs the compiled program in a memory-checking virtual machine, providing guaranteed detection of a subset of runtime memory errors. However, it typically slows the program down by a factor of 40,[10] and furthermore must be explicitly informed of custom memory allocators.[11][12]

With access to the source code, libraries exist that collect and track legitimate values for pointers ("metadata") and check each pointer access against the metadata for validity, such as the Boehm garbage collector.[13] In general, memory safety can be safely assured using tracing garbage collection and the insertion of runtime checks on every memory access; this approach has overhead, but less than that of Valgrind. All garbage-collected languages take this approach.[1] For C and C++, many tools exist that perform a compile-time transformation of the code to do memory safety checks at runtime, such as CheckPointer[14] and AddressSanitizer which imposes an average slowdown factor of 2.[15]

Another approach uses static program analysis and automated theorem proving to ensure that the program is free of memory errors. For example, the Rust programming language implements a borrow checker to ensure memory safety.[16] Tools such as Coverity offer static memory analysis for C.[17] C++'s smart pointers are a limited form of this approach.

Types of memory errors

Many different types of memory errors can occur:[18][19]


  1. ^ a b c Dhurjati, Dinakar; Kowshik, Sumant; Adve, Vikram; Lattner, Chris (1 January 2003). "Memory Safety Without Runtime Checks or Garbage Collection" (PDF). Proceedings of the 2003 ACM SIGPLAN Conference on Language, Compiler, and Tool for Embedded Systems. ACM: 69–80. doi:10.1145/780732.780743. ISBN 1581136471. S2CID 1459540. Retrieved 13 March 2017.
  2. ^ Koenig, Andrew. "How C Makes It Hard To Check Array Bounds". Dr. Dobb's. Retrieved 13 March 2017.
  3. ^ Akritidis, Periklis (June 2011). "Practical memory safety for C" (PDF). Technical Report - University of Cambridge. Computer Laboratory. University of Cambridge, Computer Laboratory. ISSN 1476-2986. UCAM-CL-TR-798. Retrieved 13 March 2017.
  4. ^ Anderson, James P. "Computer Security Planning Study" (PDF). 2. Electronic Systems Center. ESD-TR-73-51. ((cite journal)): Cite journal requires |journal= (help)
  5. ^ a b van der Veen, Victor; dutt-Sharma, Nitish; Cavallaro, Lorenzo; Bos, Herbert (2012). "Memory Errors: The Past, the Present, and the Future" (PDF). Lecture Notes in Computer Science. 7462 (RAID 2012): 86–106. doi:10.1007/978-3-642-33338-5_5. ISBN 978-3-642-33337-8. Retrieved 13 March 2017.
  6. ^ Wojtczuk, Rafal. "Defeating Solar Designer's Non-executable Stack Patch". Retrieved 13 March 2017.
  7. ^ Berger, Emery D.; Zorn, Benjamin G. (1 January 2006). "DieHard: Probabilistic Memory Safety for Unsafe Languages" (PDF). Proceedings of the 27th ACM SIGPLAN Conference on Programming Language Design and Implementation. ACM: 158–168. doi:10.1145/1133981.1134000. S2CID 8984358. Retrieved 14 March 2017.
  8. ^ Novark, Gene; Berger, Emery D. (1 January 2010). "DieHarder: Securing the Heap" (PDF). Proceedings of the 17th ACM Conference on Computer and Communications Security. ACM: 573–584. doi:10.1145/1866307.1866371. S2CID 7880497. Retrieved 14 March 2017.
  9. ^ "Memory Debugging in Allinea DDT". Archived from the original on 2015-02-03.
  10. ^ Gyllenhaal, John. "Using Valgrind's Memcheck Tool to Find Memory Errors and Leaks". Archived from the original on 7 November 2018. Retrieved 13 March 2017.
  11. ^ "Memcheck: a memory error detector". Valgrind User Manual. Retrieved 13 March 2017.
  12. ^ Kreinin, Yossi. "Why custom allocators/pools are hard". Proper Fixation. Retrieved 13 March 2017.
  13. ^ "Using the Garbage Collector as Leak Detector". Retrieved 14 March 2017.
  14. ^ "Semantic Designs: CheckPointer compared to other safety checking tools". Semantic Designs, Inc.
  15. ^ "AddressSanitizerPerformanceNumbers". GitHub.
  16. ^ "References". The Rustonomicon. Retrieved 13 March 2017.
  17. ^ Bessey, Al; Engler, Dawson; Block, Ken; Chelf, Ben; Chou, Andy; Fulton, Bryan; Hallem, Seth; Henri-Gros, Charles; Kamsky, Asya; McPeak, Scott (1 February 2010). "A few billion lines of code later". Communications of the ACM. 53 (2): 66–75. doi:10.1145/1646353.1646374. Retrieved 14 March 2017.
  18. ^ Gv, Naveen. "How to Avoid, Find (and Fix) Memory Errors in your C/C++ Code". Retrieved 13 March 2017.
  19. ^ "CWE-633: Weaknesses that Affect Memory". Community Weakness Enumeration. MITRE. Retrieved 13 March 2017.
  20. ^ "CWE-762: Mismatched Memory Management Routines". Community Weakness Enumeration. MITRE. Retrieved 13 March 2017.