Memory Safety is a Useless Concept · GitHub
/" data-turbo-transient="true" />
Skip to content
-->
Search Gists
Search Gists
Sign in
Sign up
You signed in with another tab or window. Reload to refresh your session.<br>You signed out in another tab or window. Reload to refresh your session.<br>You switched accounts on another tab or window. Reload to refresh your session.
Dismiss alert
{{ message }}
Instantly share code, notes, and snippets.
manikndn-m/memsafe-useless.md
Last active<br>August 6, 2026 12:51
Show Gist options
Download ZIP
Star
(0)
You must be signed in to star a gist
Fork
(0)
You must be signed in to fork a gist
Embed
Select an option
Embed<br>Embed this gist in your website.
Share<br>Copy sharable link for this gist.
Clone via HTTPS<br>Clone using the web URL.
No results found
Learn more about clone URLs
Clone this repository at <script src="https://gist.github.com/manikndn-m/cc820394c0f02f33cf70f96a00ba2451.js"></script>
" readonly="readonly" data-autoselect="true" data-target="primer-text-field.inputElement " aria-describedby="validation-41891932-f5ee-4df7-8b3a-2f85433c3dd5" class="form-control FormControl-monospace FormControl-input FormControl-small rounded-left-0 rounded-right-0 border-right-0" type="text" name="gist-share-url-sized-down" />
Save manikndn-m/cc820394c0f02f33cf70f96a00ba2451 to your computer and use it in GitHub Desktop.
Embed
Select an option
Embed<br>Embed this gist in your website.
Share<br>Copy sharable link for this gist.
Clone via HTTPS<br>Clone using the web URL.
No results found
Learn more about clone URLs
Clone this repository at <script src="https://gist.github.com/manikndn-m/cc820394c0f02f33cf70f96a00ba2451.js"></script>
" readonly="readonly" data-autoselect="true" data-target="primer-text-field.inputElement " aria-describedby="validation-430e3af9-7adc-4293-9d9d-36a4409b81ba" class="form-control FormControl-monospace FormControl-input FormControl-small rounded-left-0 rounded-right-0 border-right-0" type="text" name="gist-share-url-original" />
Save manikndn-m/cc820394c0f02f33cf70f96a00ba2451 to your computer and use it in GitHub Desktop.
Download ZIP
Memory Safety is a Useless Concept
Raw
memsafe-useless.md
Memory Safety is a Useless Concept
Over the last decade or so, there has been a strong push towards languages that are considered "memory safe", citing security as the primary reason. However, most security benefits attributed to memory safety languages can be very easily achieved by applying certain mitigations to unsafe languages:
Bounds checking : Eliminates all buffer overflows/underflows. Requires language support.
Control-flow Integrity (CFI) : Checks whether indirect jumps (function pointers/vtable) are valid (at runtime). This mitigation when combined with hardware mitigations like Intel CET would prevent all remote-code execution (RCE) attacks.
Type-stable allocators : Traditional memory allocators reuse the set of same memory regions for objects of approximately same size (called "size classes"). The problem that would arise here is that when a use-after-free occurs and the two successive objects are of different data types, this could enable RCE attacks (this is known as type confusion). For example, a function pointer could overlap with data obtained from external source. The obvious solution is to reserve the same set of memory regions for objects of similar types instead of size classes.
One might ask, "Why are type-stable allocators are needed when there is CFI?". The reason is there are certain object-reuse based attacks that can leak sensitive information. For example, consider the following structs:
struct User {<br>char secret[16];<br>};<br>...<br>struct Button {<br>char label[16];<br>};
Because these structs belong to the same size class, type confusions arising from UAF between these two types can potentially lead to leakage of sensitive data.
W^X : Ensures whether a memory page is either executable or writable (but not both) using hardware memory protection capabilities. This could prevent execution of attacker's code, because data from untrusted source would mostly reside in a writeable but not executable page.
Stack cookies : Ensures that a stack buffer overflow can not overwrite the return address. This mitigation is especially useful for languages like C where arrays do not retain bounds information.
CHERI/ARM MTE : Hardware memory safety. Most bullet-proof of all mitigations. But currently not mainstream and it will take a while until hardware-level memory safety becomes mainstream.
Coming to the relevant part: how much less secure is an unsafe language with mitigations than safe Rust or a GC'd language? Not much, I'd say. For the sake of the argument let us assume that an "unsafe language w/ mitigations" is slightly less secure than safe Rust. What does that mean for the statisic that 70% of CVEs are memory-related? Obviously, almost all of those 70% bugs would not be...