[kibwen]

No, that's not how this works. The bug being utilized by cve-rs has such roundabout requirements that it's unlikely that anyone has ever triggered it without trying (to be clear, the Rust devs plan to fix it regardless). Meanwhile, here's a memory safety bug that Fil-C fails to catch, not because of a compiler bug, but by design: https://www.reddit.com/r/cpp/comments/1v4nw0k/filc_garbage_i...

[MaulingMonkey]

I've encountered a few soundness holes in rust-lang in practice, but they've all been fixed before I managed to shoot myself in the foot with any of them:

• `std::mem::uninitialized()`. It's now deprecated in favor of `MaybeUninit`.

• `std::env::set_var(...)`. It's now marked `unsafe`. While I dodged the bullet, these fellows didn't: https://www.geldata.com/blog/c-stdlib-isn-t-threadsafe-and-e...

• `#[no_mangle]`. It's now `#[unsafe(no_mangle)]`.

I don't believe I've constructed cvs-rs's hole by accident. cve-rs's code links to https://github.com/rust-lang/rust/issues/25860 , which is admittedly still open after a decade. Progress appears to still be ongoing though! Related:

• https://github.com/orgs/rust-lang/projects/44/views/1

• https://rust-lang.github.io/rust-project-goals/2025h2/next-s...

> Meanwhile, here's a memory safety bug that Fil-C fails to catch, not because of a compiler bug, but by design: [...]

Thanks for sharing a concrete example of Fil-C's limitations! Disappointing - but not unexpected - to see it underperforming existing sanitizers. I was hoping for better.

[kibwen]

> I've encountered a few soundness holes in rust-lang in practice

Indeed, I'm trying to be careful not to claim that merely fixing #25860 at long last would make Rust's implementation suddenly beyond reproach. For that, we would need formal verification (which, so far, has at least been done by Ralf Jung's group for proving the correctness of large swathes of the standard library, but I wouldn't expect that to extend to the compiler anytime soon).