@kupiakos Thank you! And thanks for the detailed thoughts!

I think I basically agree with everything you said. I'm having a hard time seeing what in the post you disagree with, would you mind elaborating a bit? I certainly agree that Rust would make the bug harder to miss!

The tension between vulnerability power and exploit technique flexibility

https://pacibsp.github.io/2025/the-tension-between-vulnerability-power-and-exploit-technique-flexibility.html

"Invariant inversion" in memory-unsafe languages

https://pacibsp.github.io/2024/invariant-inversion-in-memory-unsafe-languages.html

@x43r0 Thank you! I'd love to hear, how would you frame things?

Code auditing is not the same as vulnerability research

https://pacibsp.github.io/2024/code-auditing-is-not-the-same-as-vulnerability-research.html

Some thoughts on memory safety

https://pacibsp.github.io/2024/some-thoughts-on-memory-safety.html

This post briefly describes some theoretical aspects of memory safety that feel important to me but that aren't always obvious from how I see memory safety being discussed:

1. Memory unsafety is a specific instance of a more general pattern of handle/object unsafety

2. Memory unsafety is relative to a particular layer in a stack of abstract machines

3. Memory unsafety matters because it violates local reasoning about state

4. Safe languages use invariants to provide memory safety, but these invariants do not define memory safety

Also, not sure what was up with the embed in my last post, hopefully this one works.

Why exploits prefer memory corruption

Thanks to @HalvarFlake and @chompie1337!

https://pacibsp.github.io/2024/why-exploits-prefer-memory-corruption.html