Hubbry Logo
Memory safetyMemory safetyMain
Open search
Memory safety
Community hub
Memory safety
logo
7 pages, 0 posts
0 subscribers
Be the first to start a discussion here.
Be the first to start a discussion here.
Memory safety
Memory safety
Memory safety
View on Wikipedia
from Wikipedia

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]

History

[edit]

Memory errors were first considered in the context of resource management (computing) 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.

Impact

[edit]

In 2019, a Microsoft security engineer reported that 70% of all security vulnerabilities were caused by memory safety issues.[7] In 2020, a team at Google similarly reported that 70% of all "severe security bugs" in Chromium were caused by memory safety problems. Many other high-profile vulnerabilities and exploits in critical software have ultimately stemmed from a lack of memory safety, including Heartbleed[8] and a long-standing privilege escalation bug in sudo.[9] The pervasiveness and severity of vulnerabilities and exploits arising from memory safety issues have led several security researchers to describe identifying memory safety issues as "shooting fish in a barrel".[10]

Approaches

[edit]

Some modern high-level programming languages are memory-safe by default[citation needed], though not completely since they only check their own code and not the system they interact with. Automatic memory management in the form of garbage collection is the most common technique for preventing some of the memory safety problems, since it prevents common memory safety errors like use-after-free for all data allocated within the language runtime.[11] When combined with automatic bounds checking on all array accesses and no support for raw pointer arithmetic, garbage collected languages provide strong memory safety guarantees (though the guarantees may be weaker for low-level operations explicitly marked unsafe, such as use of a foreign function interface). However, the performance overhead of garbage collection makes these languages unsuitable for certain performance-critical applications.[1]

For languages that use manual memory management, memory safety is not usually guaranteed by the runtime. Instead, memory safety properties must either be guaranteed by the compiler via static program analysis and automated theorem proving or carefully managed by the programmer at runtime.[11] For example, the Rust programming language implements a borrow checker to ensure memory safety,[12] while C and C++ provide no memory safety guarantees. The substantial amount of software written in C and C++ has motivated the development of external static analysis tools like Coverity, which offers static memory analysis for C.[13]

DieHard,[14] its redesign DieHarder,[15] 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.[16] 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,[17] and furthermore must be explicitly informed of custom memory allocators.[18][19]

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.[20] 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[21] and AddressSanitizer which imposes an average slowdown factor of 2.[22]

BoundWarden is a new spatial memory enforcement approach that utilizes a combination of compile-time transformation and runtime concurrent monitoring techniques.[23]

Fuzz testing is well-suited for finding memory safety bugs and is often used in combination with dynamic checkers such as AddressSanitizer.

Classification of memory safety errors

[edit]

Many different types of memory errors can occur:[24][25]

  • Spatial
  • Temporal
    • Use after free – dereferencing a dangling pointer storing the address of an object that has been deleted.
    • Double free – repeated calls to free may prematurely free a new object at the same address. If the exact address has not been reused, other corruption may occur, especially in allocators that use free lists.
    • Uninitialized variables – a variable that has not been assigned a value is used. It may contain sensitive information or bits that are not valid for the type.
      • Wild pointers arise when a pointer is used prior to initialization to some known state. They show the same erratic behaviour as dangling pointers, though they are less likely to stay undetected.
      • Invalid free – passing an invalid address to free can corrupt the heap.
    • Mismatched free – when multiple allocators are in use, attempting to free memory with a deallocation function of a different allocator[26]

Contributing bugs

[edit]

Depending on the language and environment, other types of bugs can contribute to memory unsafety:

  • Stack exhaustion – occurs when a program runs out of stack space, typically because of too deep recursion. A guard page typically halts the program, preventing memory corruption, but functions with large stack frames may bypass the page, and kernel code may not have the benefit of guard pages.
  • Heap exhaustion – the program tries to allocate more memory than the amount available. In some languages, this condition must be checked for manually after each allocation.
  • Memory leak – Failing to return memory to the allocator may set the stage for heap exhaustion (above). Failing to run the destructor of an RAII object may lead to unexpected results,[27][28]
  • Null pointer dereference – A null pointer dereference will often cause an exception or program termination in most environments, but can cause corruption in operating system kernels or systems without memory protection or when use of the null pointer involves a large or negative offset. In C++, because dereferencing a null pointer is undefined behavior, compiler optimizations may cause other checks to be removed, leading to vulnerabilities elsewhere in the code.[29][30]

Some lists may also include race conditions (concurrent reads/writes to shared memory) as being part of memory safety (e.g., for access control). The Rust programming language prevents many kinds of memory-based race conditions by default, because it ensures there is at most one writer or one or more readers. Many other programming languages, such as Java, do not automatically prevent memory-based race conditions, yet are still generally considered "memory safe" languages. Therefore, countering race conditions is generally not considered necessary for a language to be considered memory safe.

References

[edit]
Revisions and contributorsEdit on WikipediaRead on Wikipedia

Memory safety

View on Grokipedia
from Grokipedia
Memory safety is a property of programming languages and systems that prevents software from accessing memory in unauthorized or invalid ways, thereby avoiding common bugs such as buffer overflows, use-after-free errors, and dangling pointers that can lead to crashes, , or security vulnerabilities. This guarantee ensures that memory operations remain within defined bounds and lifetimes, making programs more reliable and secure without relying on manual checks by developers. Key types of memory safety violations include spatial errors, like reading or writing beyond the boundaries of allocated memory buffers, and temporal errors, such as accessing freed memory or using uninitialized data. These issues arise primarily in low-level languages that provide , allowing programmers flexibility but also exposing them to risks if not handled meticulously. Memory safety bugs account for a significant portion of software vulnerabilities, with estimates indicating they cause approximately 70% of such issues across major platforms. For instance, historically around 70% of Microsoft's security vulnerabilities in the late stemmed from memory safety problems, though this reduced to about 50% by 2023; a 2019 study attributed 60-70% to and macOS ecosystems, while in Android the figure was around 70-90% in the late but has since fallen below 20% as of 2025 through adoption of memory-safe languages like . These examples highlight the pervasive impact on consumer and enterprise software, though ongoing efforts are driving reductions. Programming languages are classified as memory-safe if they enforce these protections at compile time or runtime, including managed languages like Java, Python, JavaScript, C#, Swift, and Go, which use techniques such as garbage collection and bounds checking. In contrast, languages like C and C++ are not inherently memory-safe, though mitigations like address sanitizers, fuzzing tools, and modern idioms can reduce risks in those environments. Emerging systems languages, notably Rust, achieve memory safety without garbage collection through ownership and borrowing rules verified by the compiler. Addressing memory safety has become a priority, particularly for , with the U.S. government's Office of the National Cyber Director issuing calls in 2023 to promote memory-safe languages in to curb endemic cybersecurity threats. Despite progress through tools like DARPA's AI-assisted translation of C code to and defenses such as memory reshuffling techniques, transitioning legacy codebases—billions of lines strong in sectors like defense—remains challenging and may span decades.

Fundamentals

Definition

Memory safety is a of programming languages and systems that guarantees a program cannot access invalid memory locations, thereby preventing undefined behavior arising from memory-related errors without requiring explicit checks. This guarantee ensures that all memory accesses occur only within allocated regions and respect the intended capabilities of pointers, such as their base addresses and bounds. In essence, memory safety supports local reasoning about program correctness by isolating state changes to reachable memory, avoiding interference with unreachable or unallocated areas. The scope of memory safety primarily applies to programming languages and their runtimes, where it enforces protections against improper memory manipulation. Languages like and are considered unsafe because they permit direct memory access via raw pointers, allowing programmers to bypass bounds and potentially access invalid locations. In contrast, memory-safe languages such as , , and Python incorporate mechanisms like automatic bounds checking and ownership models to prevent such accesses at or runtime. This distinction arose in the context of early systems, where in low-level languages exposed programs to frequent errors. Memory safety is distinct from related concepts like and resource safety. Type safety focuses on ensuring that operations on data adhere to their declared types, preventing misuse such as treating an as a pointer, whereas memory safety specifically targets valid memory addressing regardless of type. Resource safety, on the other hand, addresses the proper acquisition and release of resources with finite lifetimes, such as files or locks, extending beyond memory to avoid leaks or double-frees in a broader sense. A classic example of a memory safety violation is a , where a program writes data beyond the allocated bounds of an , potentially corrupting adjacent memory. For instance, in C, the code int buf[5]; buf[10] = 42; could overwrite unrelated variables or return addresses, leading to unpredictable behavior. In memory-safe languages like Python, array access is enforced through bounds checking; attempting lst = [1,2,3]; lst[10] raises an IndexError at runtime, preventing invalid access.

Core Principles

Memory safety encompasses mechanisms that prevent programs from accessing memory locations outside their intended bounds or after deallocation, thereby avoiding spatial and temporal errors. Core principles include bounds checking to enforce spatial safety by verifying that memory accesses, such as array indices, stay within allocated limits, either at compile time or runtime, and halting execution on violations to prevent overflows and underflows. For temporal safety, automatic memory management techniques like garbage collection—used in languages such as Java and Python—track and reclaim unused memory, preventing use-after-free errors and dangling pointers without manual deallocation. Alternatively, ownership and lifetime tracking, as in Rust, ensure resources are managed through compile-time rules to avoid invalid accesses. In concurrent environments, aliasing rules help prevent data races by restricting simultaneous mutable access to the same , ensuring modifications are serialized and maintaining consistency.

Historical Development

Origins

In the pre-1960s era of computing, was predominantly manual, requiring programmers to explicitly allocate and deallocate locations in for early machines like the IBM 704. This process involved direct manipulation of addresses, often leading to frequent errors such as buffer overflows, where data exceeded allocated bounds, and leaks, where unused was not reclaimed, resulting in gradual resource exhaustion. Early high-level languages like , introduced in 1957, offered some abstraction but still relied on static allocation of fixed-size arrays, exacerbating issues in resource-constrained environments with limited core , typically measured in kilobytes. Fragmentation—both internal (wasted space within blocks) and external (scattered free spaces preventing large allocations)—emerged as a foundational problem, as programmers devised ad-hoc overlay schemes to swap code segments between main and slower drums or tapes, complicating program execution and reliability. The marked a shift toward automated mechanisms to address these manual management pitfalls, with the introduction of garbage collection in high-level languages. John McCarthy developed the first garbage collector for in 1959, as part of its implementation on the , to automatically reclaim memory from objects no longer referenced by the program, thereby mitigating leaks and fragmentation without programmer intervention. This innovation, detailed in McCarthy's seminal work on recursive functions, represented an early recognition of memory safety as a core concern, enabling dynamic list structures in while reducing the cognitive burden of manual deallocation. By the early , garbage collection had influenced other languages, serving as a precursor to broader safety principles in memory handling. Concurrent with these language-level advances, the advent of systems in the 1960s underscored the need for memory isolation to support multitasking. The operating system, initiated in 1965 and first operational in 1969, pioneered segmented , where programs operated in protected address spaces to prevent interference between concurrent users. This design highlighted foundational isolation requirements, as manual memory sharing in multi-user environments amplified risks of inadvertent overwrites and fragmentation across processes. Multics' approach to hierarchical memory structures and protection rings laid groundwork for recognizing memory safety as essential for system reliability in shared computing.

Key Milestones

The , released on November 2, 1988, marked the first major real-world exploitation of a vulnerability, targeting the fingerd daemon on Unix systems to propagate across the early . This self-replicating program infected an estimated 6,000 machines, representing approximately 10% of the roughly 60,000 hosts connected to the at the time, causing widespread slowdowns and prompting the formation of the first (CERT) to coordinate defenses. In the , the technique of stack-smashing attacks gained prominence as attackers learned to overwrite return addresses on the call stack to redirect program , building on earlier concepts to enable remote code execution. These attacks were detailed in seminal publications like the 1996 Phrack article "Smashing the Stack for Fun and Profit," which popularized the method among security researchers and adversaries. Concurrently, format string vulnerabilities emerged as a related threat, allowing attackers to read or write arbitrary memory by abusing unchecked printf-like functions; CERT issued early advisories on such issues starting in the late , highlighting their prevalence in network services like SSH and . The 2000s saw increased formal recognition of memory safety issues through standards like the (CWE), launched by in 2006 to categorize software weaknesses, including CWE-119 for improper buffer bounds and related memory errors. A landmark incident was the 2014 vulnerability (CVE-2014-0160) in the library, a buffer over-read bug that exposed up to 64 kilobytes of server memory per request, potentially leaking private keys, passwords, and session cookies from affected systems. This flaw impacted an estimated 17% of HTTPS-protected web servers worldwide, affecting millions of users and organizations, and underscored the risks of memory errors in widely used cryptographic software. In the , industry leaders quantified the scale of memory safety problems, with reporting in 2019 that approximately 70% of the security vulnerabilities it remediates via CVEs stem from memory safety issues in C and C++ code. Similarly, revealed that over 70% of severe security bugs in Chrome during this period were memory safety related, driving the browser's adoption of safer coding practices, such as integrating memory-safe languages like for new components starting around 2019 to reduce vulnerability surfaces.

Classification of Errors

Spatial Errors

Spatial errors in memory safety refer to invalid accesses to memory locations due to violations of allocated bounds, distinguishing them from temporal errors that involve accesses after deallocation or during invalid states. These errors occur when a program reads from or writes to memory addresses outside the intended spatial limits of objects like buffers or arrays, potentially corrupting adjacent data structures or control information. Spatial errors are prevalent in languages like and that lack built-in bounds checking, making them a primary source of vulnerabilities in systems software. Buffer overflows represent the most common form of spatial errors, where data is written beyond the end of an allocated buffer, overwriting subsequent regions. This can lead to stack corruption if the buffer is on the stack, altering return addresses or local variables, or heap corruption if on the heap, disrupting allocation metadata like chunk sizes in dynamic managers. For instance, the classic strcpy function copies a source string into a destination buffer without verifying the destination's capacity, allowing an oversized input to overflow and potentially execute arbitrary code if the overwritten includes executable regions. Heap overflows are particularly exploited in attacks like , where attackers flood the heap with oversized allocations to increase the density of malicious payloads, facilitating control-flow hijacks when an overflow redirects execution. Buffer underflows, the counterpart to overflows, involve writing to or reading from locations before the start of an allocated buffer, similarly corrupting preceding . These errors arise from negative index calculations or misaligned pointer arithmetic, often affecting heap metadata or adjacent objects, and are noted as a significant in C/C++ applications due to unchecked array accesses. Underflows can enable similar exploit primitives as overflows, such as data leakage or , but are less frequently discussed because they manifest in less predictable layouts. Integer overflows contribute to spatial errors by causing miscalculations in buffer indices or sizes, leading to unintended bounds violations. When an arithmetic operation exceeds the representable range of an type, it wraps around, potentially allocating insufficient space or computing an invalid offset that triggers an overflow or underflow. For example, adding lengths in a buffer allocation without overflow checks can result in a too-small buffer, allowing subsequent writes to spill over. Such vulnerabilities have been documented in media processing libraries, where unchecked sums in index computations enable heap-based overflows. Detecting spatial errors poses significant challenges because they often produce no immediate symptoms, executing silently until exploited through specific inputs that reveal corruption effects like crashes or breaches. Static struggles with pointer and dynamic allocations, while runtime detection requires overhead-intensive , limiting its use in production environments. These silent failures contribute to their persistence as the top class in C/C++ codebases, with empirical studies showing they account for a substantial portion of reported issues.

Temporal Errors

Temporal errors in memory safety arise from invalid temporal access to memory, where a program attempts to use resources after their deallocation or outside their intended lifecycle, leading to and potential vulnerabilities. These errors contrast with spatial errors by focusing on timing and lifecycle mismatches rather than boundary violations. Common manifestations include use-after-free, double-free, and dangling pointers, each disrupting the proper sequencing of memory allocation and release in low-level languages like and . Use-after-free occurs when a program continues to access a pointer to that has already been deallocated, often because the pointer was not updated or cleared after freeing the resource. This can result in reading or writing to invalid locations, which may have been reallocated for other purposes, leading to , crashes, or exploitation such as . For instance, in heap management systems like glibc's malloc implementation, a use-after-free might allow an attacker to manipulate freed chunks in the heap, overwriting critical metadata and enabling further inconsistencies. Double-free happens when the same block is deallocated twice, typically due to flawed handling or confusion over responsibilities, corrupting the memory allocator's internal data structures such as free lists or bins. This inconsistency can propagate to subsequent allocations, causing heap fragmentation, unexpected reallocation of the same block, or even buffer overflows that enable code execution. In practice, double-free often compounds with use-after-free if the erroneous second free leaves dangling references intact. Dangling pointers refer to pointers that continue to hold addresses of deallocated objects, creating latent risks that turn into active errors upon dereference and often serving as the root cause of use-after-free incidents. These pointers violate temporal safety by outliving their referents, potentially leading to the interpretation of attacker-controlled data as valid program structures. typically involves nullifying pointers post-deallocation, though this does not prevent all propagation paths. Temporal errors like these tend to compound over program execution, as initial corruptions in heap metadata or pointer states can trigger cascading s in unrelated operations, amplifying reliability issues and enabling sophisticated exploits. For example, a single use-after-free may invalidate allocator invariants, causing subsequent double-frees or invalid accesses that propagate silently until a critical occurs.

Impacts

Security Consequences

Memory unsafety introduces exploitable vulnerabilities that attackers leverage to compromise systems, often through spatial errors such as buffer overflows, which allow by overwriting adjacent memory regions with malicious payloads. This can enable , granting attackers control over the affected process or system. For instance, buffer overflows have been a primary vector in numerous exploits, permitting attackers to redirect program flow and inject . Temporal errors, like use-after-free, facilitate information leaks by accessing deallocated memory that may contain sensitive data, such as cryptographic keys or user credentials, without triggering immediate crashes. These leaks can expose confidential information, aiding further attacks like privilege escalation. Real-world statistics underscore the prevalence of these vulnerabilities. Microsoft reported that approximately 70% of the security vulnerabilities it fixed and assigned CVEs to stemmed from memory safety issues. Similarly, analysis by Google's Project Zero found that 67% of zero-day vulnerabilities exploited in the wild during 2021 were memory safety related, with a significant portion targeting iOS and macOS ecosystems. The Heartbleed vulnerability, a buffer over-read in the OpenSSL library, exemplified this risk by affecting roughly 17% of HTTPS servers worldwide upon its 2014 disclosure, enabling widespread data exfiltration from secure connections. Attackers frequently chain memory safety flaws with bypass techniques to amplify impact, such as defeating (ASLR) to predict memory locations for precise exploitation. The 2017 WannaCry outbreak illustrates this, exploiting a in Windows SMBv1 (known as ) to self-propagate across networks, infecting over 200,000 systems in 150 countries and evading mitigations through worm-like behavior. The economic toll of such exploits is substantial, with breaches attributed to memory unsafety costing billions globally. WannaCry alone inflicted an estimated $4 billion in financial and productivity losses, including disrupted healthcare and manufacturing operations. remediation efforts, involving certificate revocations and system updates, added tens of millions more in direct costs to businesses, highlighting the broader fiscal burden of these vulnerabilities. Recent analyses as of 2025 indicate progress, with memory safety vulnerabilities comprising less than 20% of total vulnerabilities in some major products due to increased adoption of safe languages and tools.

Reliability Effects

Memory unsafety in software systems frequently manifests as crashes, often triggered by invalid memory accesses such as dereferencing null pointers or accessing freed memory regions. These errors commonly result in segmentation faults, which abruptly terminate program execution and halt system operations. Such crashes introduce significant unpredictability during debugging, as the failure symptoms may appear distant from the root cause due to the non-deterministic nature of memory corruption propagation. In production environments, these incidents disrupt service continuity, requiring manual intervention or restarts that exacerbate operational overhead. Beyond immediate failures, memory unsafety can lead to data corruption through silent overwrites, where erroneous writes alter program state without triggering detectable errors. For instance, buffer overflows in C or C++ code may overwrite adjacent memory areas, leading to incorrect computations or inconsistent data outputs that persist undetected until they cascade into broader system malfunctions. This type of corruption undermines the integrity of calculations in safety-critical applications, potentially propagating errors through dependent modules and resulting in unreliable results over time. Performance degradation represents another key reliability impact, primarily from memory leaks that cause gradual resource exhaustion. Unreleased memory allocations accumulate, increasing heap usage until available memory is depleted, which forces excessive paging or swapping and slows system responsiveness. Additionally, repeated allocations and deallocations without proper can induce memory fragmentation, where free memory becomes scattered into non-contiguous blocks, complicating future allocations and further reducing allocation efficiency. Real-world examples illustrate these effects in high-stakes domains. In web applications, undetected memory leaks in server-side code have led to halts and unplanned downtime; production leaks in cloud-based services can escalate to full server unavailability after prolonged operation.

Approaches

Language Mechanisms

Programming languages incorporate various built-in mechanisms to enforce memory safety, preventing common errors such as buffer overflows, dangling pointers, and use-after-free vulnerabilities at or runtime. These features range from automatic to static checks on resource lifetimes and access bounds, allowing developers to write safer code without manual intervention in allocation and deallocation. Garbage collection (GC) is a prominent runtime mechanism for automatic , reclaiming memory occupied by unreachable objects to eliminate manual deallocation and associated errors like double frees or leaks. In , the (JVM) implements generational GC, which divides the heap into young and old generations to efficiently collect short-lived objects while minimizing pauses for long-lived ones. Python employs a combination of for immediate deallocation and a cyclic GC to detect and resolve reference cycles that reference counting alone cannot handle, ensuring comprehensive memory reclamation without explicit programmer intervention. This approach in both languages inherently prevents use-after-free and issues by automating lifetime management. Bounds checking on arrays and similar data structures is another compile-time or runtime safeguard, verifying that index accesses remain within declared limits to avert spatial memory errors like buffer overruns. The Ada programming language mandates bounds-checked array indexing as part of its type system, raising a Constraint_Error exception if an index exceeds the array's bounds, thereby enforcing safe access without runtime overhead in optimized code paths. This feature, integral to Ada's design for high-reliability systems, catches invalid accesses early and prevents undefined behavior, contrasting with unchecked languages like C. Ownership and borrowing rules provide compile-time guarantees against temporal memory errors by tracking resource lifetimes and access permissions. In Rust, the ownership model assigns each value a single owner responsible for its deallocation, while borrowing allows temporary references under strict rules enforced by the borrow checker—a static analyzer that rejects code permitting multiple mutable references or use after a borrow's scope ends. This prevents data races, dangling pointers, and invalid mutations at compile time, enabling safe concurrency without a garbage collector. Region-based memory management offers an alternative to traditional GC by statically defining memory regions with explicit lifetimes, allowing bulk deallocation and finer control. The language, a safe dialect of , uses regions to group allocations, where pointers are typed to specific regions and checked at to ensure they do not outlive their region's scope, thus avoiding leaks and invalid accesses without runtime GC overhead. 's region inference and tagged unions further support safe low-level programming by restricting pointer arithmetic to region bounds. While these mechanisms enhance safety, they introduce trade-offs in and . Garbage collection, for instance, incurs runtime pauses during collection cycles, where the mutator threads halt to allow marking and sweeping, potentially disrupting real-time applications; generational collectors mitigate this by tuning pause frequency against throughput, but overhead can reach 10-20% in allocation-intensive workloads. Compile-time checks like Rust's borrow checker or Ada's bounds verification may require code restructuring, increasing development time, though they eliminate entire classes of runtime errors. Region-based systems balance this by reducing deallocation costs through scoped bulk freeing, but demand precise region annotations to avoid errors.

Tools and Protections

Sanitizers are runtime tools integrated into compilers like GCC and to detect memory errors in and C++ programs. AddressSanitizer (ASan), developed by , instruments code to identify spatial errors such as buffer overflows on the heap, stack, and globals, as well as temporal errors like use-after-free accesses, by maintaining a shadow memory map that tracks valid memory regions. It operates with minimal false positives and has been widely adopted in for and testing. Valgrind is a dynamic framework that provides detailed detection of leaks, invalid accesses, and uninitialized value usage through its Memcheck tool, which uses bit-level tracking of states during program execution. Memcheck simulates the program's execution on a synthetic CPU, intercepting operations to verify their validity, making it effective for uncovering subtle errors in legacy codebases. Hardware-based protections enhance memory safety at the system level. The (MMU) enforces page-level protections by translating virtual addresses to physical ones and restricting access based on permissions like read-only or no-execute, preventing unauthorized modifications or executions that could exploit memory errors. (ASLR) complements this by randomly positioning key memory regions such as the stack, heap, and libraries at load time, increasing the difficulty of predicting addresses for exploitation attempts like buffer overflows. Static analyzers scan source code without execution to identify potential memory errors. Coverity, a commercial tool, uses dataflow analysis to detect issues like memory leaks and buffer overruns by modeling code paths and variable lifetimes, and it has been applied to large-scale projects to uncover defects in billions of lines of code. These tools can be used alongside language mechanisms for comprehensive protection in unsafe languages, though they introduce trade-offs. For instance, AddressSanitizer typically incurs about a 2x runtime slowdown and increased memory usage due to instrumentation and shadow mapping. Valgrind's overhead is higher, typically 10–50 times slower, owing to its full simulation approach. Static tools like Coverity add no runtime cost but may produce false positives requiring manual review.

Recent Advances

Policy Initiatives

In December 2024, the White House Office of the National Cyber Director (ONCD) reiterated its call for federal agencies to prioritize memory-safe languages like in to mitigate vulnerabilities in government systems. This builds on the ONCD's February 2024 technical report, which recommended migrating legacy codebases from unsafe languages such as and to memory-safe alternatives, emphasizing 's borrow checker to prevent common errors like buffer overflows and use-after-free bugs. In June 2025, the Cybersecurity and Infrastructure Security Agency (CISA) and the National Security Agency (NSA) jointly released a Cybersecurity Information Sheet providing a roadmap for adopting memory-safe languages (MSLs) in critical infrastructure sectors. The guide outlines strategies for organizations to transition new development and high-risk components to MSLs like Rust, Go, Java, Python, and Swift, aiming to reduce memory-related vulnerabilities through built-in safeguards and developer training. It highlights the need for published adoption roadmaps to enhance security in areas such as network services and embedded systems, without specifying a fixed elimination timeline but stressing long-term risk reduction. These policies are driven by stark statistics on memory safety risks; for instance, memory safety issues accounted for 76% of Android vulnerabilities in 2019 but fell to 24% by 2024 following Google's adoption of MSLs like for new code, demonstrating the effectiveness of such transitions. Additionally, memory safety known exploited vulnerabilities (KEVs) continued to rise across industries from operating systems to industrial control systems in 2024, underscoring the urgency for broader adoption. In the industry sector, pledged in November 2023 under its Secure Future Initiative to transition to memory-safe languages for new products and existing codebases, with a 2025 update confirming ongoing investments in for platforms like and firmware. In November 2025, released a progress report detailing further advancements, including -based firmware and drivers for devices. This commitment aligns with federal guidance, aiming to eliminate risks through phased adoption.

Emerging Frameworks

The OpenSSF's Memory Safety Continuum, released in April 2025, provides an iterative for organizations to assess and enhance memory safety in software projects, progressing from basic vulnerability detection to complete migration to memory-safe languages (MSLs). This framework categorizes safety levels on a spectrum, with the highest tier involving code written entirely in MSLs like or Go, and lower tiers incorporating runtime protections or partial rewrites, enabling gradual adoption in legacy systems without full overhauls. It emphasizes practical steps, such as integrating safe dependencies and using automated tools for detection, to address gaps in C/C++-dominated ecosystems. Google's Carbon language, introduced as a C++ successor in 2022 and advanced through 2024 and 2025 roadmaps, incorporates memory safety guarantees via and compile-time checks to prevent spatial and temporal errors. Carbon's design supports incremental adoption, allowing developers to migrate C++ code gradually while maintaining , with features like automated refactoring tools to enforce bounds checking without runtime overhead in safe modes. By 2025, prototypes demonstrated near-zero safety violations in benchmarked applications, positioning it as a bridge for high-performance systems resistant to full MSL transitions. The ecosystem has seen significant expansions in 2025, particularly in tools for safe (FFI) interactions, highlighted at RustConf 2025 where sessions focused on ergonomic C/C++ bindings to mitigate safety risks in mixed-language environments. These include abstractions like safe wrappers over unsafe FFI calls, reducing exposure to buffer overflows and use-after-free errors during interop. Complementing this, the Prossimo project by the (ISRG) advances safe C replacements through Rust-based drop-in libraries, such as reimplementations of critical components like , ensuring ABI compatibility while eliminating memory vulnerabilities. Hybrid approaches, such as BoundWarden, originally proposed for compile-time spatial safety enforcement via thread-local bounds tracking, offer protections against out-of-bounds accesses code. Such methods enable retrofitting safety into existing systems, particularly in embedded or kernel contexts where full rewrites are infeasible. Despite these advances, interoperability with unsafe code remains a key challenge, as FFI boundaries and legacy integrations can introduce vulnerabilities that bypass language-level protections, necessitating ongoing verification efforts. Policy initiatives, such as those from CISA and OpenSSF, have facilitated funding and standards that accelerate these technical developments.

References

  1. https://www.memorysafety.org/docs/memory-safety/
  2. https://cset.georgetown.edu/article/memory-safety-an-explainer/
  3. https://news.mit.edu/2025/memory-safety-tipping-point-0618
  4. https://media.defense.gov/2025/Jun/23/2003742198/-1/-1/0/CSI_MEMORY_SAFE_LANGUAGES_REDUCING_VULNERABILITIES_IN_MODERN_SOFTWARE_DEVELOPMENT.PDF
  5. https://security.googleblog.com/2025/11/
  6. https://arxiv.org/abs/1705.07354
  7. http://www.pl-enthusiast.net/2014/07/21/memory-safety/
  8. https://borretti.me/article/type-systems-memory-safety
  9. https://hacks.mozilla.org/2019/01/fearless-security-memory-safety/
  10. https://www.microsoft.com/en-us/msrc/blog/2019/07/we-need-a-safer-systems-programming-language
  11. https://people.mpi-sws.org/~dreyer/papers/safe-sysprog-rust/paper.pdf
  12. http://denninginstitute.com/pjd/PUBS/bvm.pdf
  13. https://cics.umass.edu/~emery/classes/cmpsci691st/readings/OS/multics-overview.pdf
  14. https://spaf.cerias.purdue.edu/tech-reps/823.pdf
  15. https://courses.cs.washington.edu/courses/cse484/10wi/lectures/Lecture03-2010.pdf
  16. https://cs155.stanford.edu/papers/formatstring-1.2.pdf
  17. https://www.heartbleed.com/
  18. https://www.csoonline.com/article/562859/the-heartbleed-bug-how-a-flaw-in-openssl-caused-a-security-crisis.html
  19. https://security.googleblog.com/2021/09/an-update-on-memory-safety-in-chrome.html
  20. https://dl.acm.org/doi/10.1145/1543135.1542504
  21. https://owasp.org/www-community/vulnerabilities/Buffer_Overflow
  22. https://dl.acm.org/doi/fullHtml/10.5555/327850.327875
  23. https://owasp.org/www-project-web-security-testing-guide/v41/4-Web_Application_Security_Testing/07-Input_Validation_Testing/13.1-Testing_for_Heap_Overflow
  24. https://dl.acm.org/doi/10.1145/2892208.2892212
  25. https://dl.acm.org/doi/fullHtml/10.1145/3551349.3561161
  26. https://dl.acm.org/doi/10.1145/2714576.2714605
  27. https://nvd.nist.gov/vuln/detail/CVE-2021-21843
  28. https://dl.acm.org/doi/10.1145/1882291.1882338
  29. https://dl.acm.org/doi/10.1145/3626787
  30. https://cwe.mitre.org/data/definitions/416.html
  31. https://blog.quarkslab.com/heap-exploitation-glibc-internals-and-nifty-tricks.html
  32. https://cwe.mitre.org/data/definitions/415.html
  33. https://owasp.org/www-community/vulnerabilities/Using_freed_memory
  34. https://user.eng.umd.edu/~barua/scam.pdf
  35. https://www.imperva.com/learn/application-security/buffer-overflow/
  36. https://www.cyber.gov.au/business-government/secure-design/secure-by-design/case-memory-safe-roadmaps
  37. https://www.netcraft.com/blog/half-a-million-widely-trusted-websites-vulnerable-to-heartbleed-bug
  38. https://www.cloudflare.com/learning/security/ransomware/wannacry-ransomware/
  39. https://www.cbsnews.com/news/wannacry-ransomware-attacks-wannacry-virus-losses/
  40. https://www.theguardian.com/technology/2014/apr/18/heartbleed-bug-will-cost-millions
  41. https://dl.acm.org/doi/10.1145/3728360
  42. https://dl.acm.org/doi/pdf/10.1145/3639477.3640328
  43. http://www.cs.columbia.edu/~simha/thesis/Hassan_columbia_0054D_17173.pdf
  44. https://media.defense.gov/2022/Nov/10/2003112742/-1/-1/1/CSI_SOFTWARE_MEMORY_SAFETY.PDF
  45. https://www.usenix.org/system/files/atc21-wang-wenwen.pdf
  46. https://people.cs.umass.edu/~emery/pubs/pldi101-novark.pdf
  47. https://www.usenix.org/system/files/osdi22-lou-resin.pdf
  48. https://dl.acm.org/doi/10.1145/512529.512563
  49. https://dl.acm.org/doi/10.1145/2887746.2754185
  50. https://docs.python.org/3/library/gc.html
  51. https://legacy.python.org/workshops/1997-10/proceedings/hugunin.html
  52. https://mail.sigada.hosting.acm.org/ada_letters/aug2010/Ada_SPARK_Vulnerabilities_Annexes.pdf
  53. https://www.adaic.org/resources/add_content/standards/95rat/rat95html/rat95-p3-h.html
  54. https://doc.rust-lang.org/book/ch04-01-what-is-ownership.html
  55. https://doc.rust-lang.org/book/ch04-00-understanding-ownership.html
  56. https://dl.acm.org/doi/10.1145/1029873.1029883
  57. https://dl.acm.org/doi/fullHtml/10.1145/3546918.3546926
  58. https://research.google.com/pubs/archive/37752.pdf
  59. https://www.usenix.org/conference/2005-usenix-annual-technical-conference/using-valgrind-detect-undefined-value-errors-bit
  60. https://valgrind.org/docs/pubs.html
  61. https://www.nxp.com/docs/en/supporting-information/TPQ2CH09.pdf
  62. https://dl.acm.org/doi/10.1145/1030083.1030124
  63. https://dl.acm.org/doi/10.1145/1646353.1646374
  64. https://valgrind.org/docs/manual/manual-core.html
  65. https://stackoverflow.blog/2024/12/30/in-rust-we-trust-white-house-office-urges-memory-safety/
  66. https://bidenwhitehouse.archives.gov/wp-content/uploads/2024/02/Final-ONCD-Technical-Report.pdf
  67. https://www.cisa.gov/resources-tools/resources/memory-safe-languages-reducing-vulnerabilities-modern-software-development
  68. https://www.nsa.gov/Press-Room/Press-Releases-Statements/Press-Release-View/Article/4223298/nsa-and-cisa-release-csi-highlighting-importance-of-memory-safe-languages-in-so/
  69. https://security.googleblog.com/2024/09/eliminating-memory-safety-vulnerabilities-Android.html
  70. https://runsafesecurity.com/blog/memory-safety-kevs-increasing/
  71. https://www.microsoft.com/en-us/security/blog/2025/04/17/microsofts-secure-by-design-journey-one-year-of-success/
  72. https://www.microsoft.com/en-us/security/blog/2025/11/10/securing-our-future-november-2025-progress-report-on-microsofts-secure-future-initiative/
  73. https://www.microsoft.com/trust-center/security/secure-future-initiative
  74. https://openssf.org/blog/2025/04/28/announcing-the-release-of-the-memory-safety-continuum/
  75. https://memorysafety.openssf.org/memory-safety-continuum/
  76. https://github.com/carbon-language/carbon-lang
  77. https://security.googleblog.com/2024/10/safer-with-google-advancing-memory.html
  78. https://lwn.net/Articles/1036912/
  79. https://rustconf.com/schedule-tag/memory-safety/
  80. https://www.memorysafety.org/
  81. https://dl.acm.org/doi/10.1007/978-3-030-93206-0_2
  82. https://www.youtube.com/watch?v=cOP219vkax8
  83. https://www.cisa.gov/news-events/alerts/2025/06/24/new-guidance-released-reducing-memory-related-vulnerabilities
Add your contribution
Related Hubs
User Avatar
No comments yet.