How memory safety CVEs differ between Rust and C/C++ • Hacker News Board

Re: How memory safety CVEs differ between Rust and C/C++

#131

Post by josephg » Tue, Jun 16, 2026, 2:47 AM UTC

Decabytes wrote: post #90

Bjarne Stroustrup was recently interviewed by Ryan Peterman^1 1. https://youtu.be/U46fJ2bJ-co?t=2780 and Ryan asked Bjarne about memory safety. Bjarne brushes it off and says that in almost all cases where we see memory safety issues, they are either 1. Being written in C style C++ and not using "Modern C++" 2. Being written in C He then goes on to say say that Modern C++ and where it is necessary, hardened libraries…

If these hardened libraries were as good, we wouldn't have blog posts like this[1], from the android team last year.

> We adopted Rust for its security and are seeing a 1000x reduction in memory safety vulnerability density compared to Android’s C and C++ code

Maybe the android team could have gotten the same benefits by simply auditing and modernising their C++ code? I'm not convinced. Google has some amazing engineers. They've been using hardened standard library variants for a long time - much longer than they've been part of the C++ standard. If google is still getting large security benefits from adopting rust, I think the benefit in rust is real and Bjarne Stroustrup is wrong.

[1] https://blog.google/security/rust-in-android-move-fast-fix-t...

Re: How memory safety CVEs differ between Rust and C/C++

#132

Post by insanitybit » Tue, Jun 16, 2026, 2:52 AM UTC

bitbasher wrote: post #62

Memory safety is a concern, but there are many solutions that don't include Rust. Rust is certainly one solution, though. However, Rust seems to trade memory safety vulnerabilities for supply chain risk.

It's not a trade. It isn't "because we got memory safety we have to lose supply chain security". Rust, like every other language, has put minimal preemptive effort into supply chain security. There's recently basic stuff like Trusted Publishing and dependency cooldowns are on the way, but that's it in terms of native features - nothing novel or special, really.

Thankfully the community has built `cargo-vet`, which is basically a best-in-class distributed auditing system.

Re: How memory safety CVEs differ between Rust and C/C++

#133

Post by kwveddlsjggej » Tue, Jun 16, 2026, 2:55 AM UTC

dtornabene wrote: post #96

kkishahva wrote: post #92

Earlier quoted context omitted.

[flagged]

yeah this is absurd and a brand new account pushing it too.

They've been registering new accounts to bring this up in Rust-related threads for months. Their tone has escalated from concern to vitriol, and this is the first I'm seeing open calls for violence.

Commenter, whoever you are, I sincerely hope you have people in your life to talk to and that you are doing okay. I am genuinely concerned.

Re: How memory safety CVEs differ between Rust and C/C++

#134

Post by armitron » Tue, Jun 16, 2026, 3:25 AM UTC

okanat wrote: post #111

bitbasher wrote: post #71

Earlier quoted context omitted.

Rust's standard library is incredibly thin (intentionally so). As a result, you need to use the crate ecosystem. This comes with some downsides. 1. Each crate you depend on generally comes with dozens of its own dependencies. 2. A large number of crates have few downloads. You can use blessed.rs to try an find "trusted" dependencies. 3. Cargo comes with "build.rs" for compile time code execution. Basically, your code…

> Rust's standard library is incredibly thin (intentionally so). As a result, you need to use the crate ecosystem. This comes with some downsides. This is no different than C++. C++ standard library made so many compromises in the name of ABI compatibility almost none of the library is actually usable for any use case. So people start to quickly add things like boost, abseil, folly, Qt, asio, imgui, doctest etc. Ther…

I've never seen a C program use hundreds of dependencies. This is typical in Rust (and Node). I know a few high assurance teams that dropped Rust for this very reason.

Re: How memory safety CVEs differ between Rust and C/C++

#135

Post by armitron » Tue, Jun 16, 2026, 3:27 AM UTC

dralley wrote: post #105

bitbasher wrote: post #83

Earlier quoted context omitted.

Most dependencies in the C/C++ world come with fewer dependencies of their own (at least, an order of magnitude fewer than the average rust dependency). Perhaps a Makefile could be considered arbitrary code execution, but we've been running Makefiles for 50 years and we haven't had the supply chain issues we see in NPM, etc. Supply chain risk was always considered in the C/C++ world... think back to Ken Thompson's 19…

But how often do people just copy and paste code in the C/C++ ecosystem? Or reimplement things badly? Last I checked VLC had a homegrown XML parser.

Experts know that copy/pasting and/or reimplementing code is not an issue in practice regardless of how often it comes up as an anti-pattern in freshman CS courses. The (amalgamated) software system can still be audited in reasonable time as long as the number of third party dependencies is kept low.

Rust has thrown the baby out with the bathwater in that regard resulting in software that is practically impossible to audit without putting in enormous effort.

Re: How memory safety CVEs differ between Rust and C/C++

#136

Post by thayne » Tue, Jun 16, 2026, 4:28 AM UTC

cesaref wrote: post #29

Is it only me that would have expected curl_getenv() to have an assert that it's argument isn't NULL? I know this doesn't stop runtime problems in release builds, but i'd have thought this sort of simple precondition check would help users find problems in their library useage. It's not going to stop you passing a non-terminated string, or other such invalid input though, which is I guess more the point, that it's to…

> it's not possible to add a precondition without introducing a runtime overhead

Indeed. Adding an assertion to a single function isn't a big deal, but if every function has to check all of it's arguments, that's going to add up. And even if you could have the assertion only in debug builds, that isn't enough unless you have a very exhaustive test suite, because an edge case could trigger undefined behavior in production in a way that wasn't exercised during testing.

In fact, the fact that the rust compiler adds runtime checks for array indexes if it can't prove the index is in bounds is a criticism some c programmers have of rust.

Re: How memory safety CVEs differ between Rust and C/C++

#137

Post by pornel » Tue, Jun 16, 2026, 4:30 AM UTC

thegrim33 wrote: post #65

Really annoying when people take 50 year old C code and modern C++ code and just drop them into the same bucket and refer to them as if they're the same thing. The CURL example they give has multiple modern C++ solutions that accomplish the same thing without UB.

This doesn't change a thing, because Rust is an answer to Modern C++ still being inherently unsafe and not meeting the bar. The best that C++26 has to offer is below the basic guarantees that Rust shipped in 2015.

This is the blind spot that prevents Bjarne from taking significant steps needed for C++ to catch up. He's still seeing C/C++98 as the problem to solve, while Rust sees Modern C++ as the problem to solve.

Re: How memory safety CVEs differ between Rust and C/C++

#138

Post by uecker » Tue, Jun 16, 2026, 4:56 AM UTC

lmm wrote: post #117

jstimpfle wrote: post #108

Earlier quoted context omitted.

A bug is a bug even when it doesn't clearly manifest itself 100% of the time, and furthermore it is pretty much guaranteed that NULL dereference crashes with segfault in practice, only not for the people playing theoretic games whose essence of life is finding gotchas where it maybe isn't so and then feeling smarter than everyone else. But it's >> 99.9% true that this will just crash even though it's acshually UB, na…

> it's >> 99.9% true that this will just crash even though it's acshually UB, nasal demons and so forth. Is it though? Linux saw enough bugs from that kind of issue that they now build with -fno-delete-null-pointer-checks and accept the (supposed) performance penalty.

The kernel is perhaps bit special. In the past they had bugs such as first derferencing and then checking for null and weird possibilities to map the zero page. But today I am not convinced this is really needed.

In general on a system where you trap when accessing the zero page, this optimization should be safe and a null pointer dereferences should (safely) trap.

Re: How memory safety CVEs differ between Rust and C/C++

#139

Post by uecker » Tue, Jun 16, 2026, 4:57 AM UTC

asveikau wrote: post #123

dwattttt wrote: post #104

Earlier quoted context omitted.

An assertion is an app crashing on a violation. The problem is when it's not guaranteed to crash, and instead does something very wrong.

An assert is not guaranteed to terminate the process. In C, the most common implementation choice is to completely omit the check if you're not building in debug mode.

You need to turn it off by defining NDEBUG. While sometimes it is not for release builds, I am not sure this is common.

Re: How memory safety CVEs differ between Rust and C/C++

#140

Post by uecker » Tue, Jun 16, 2026, 5:00 AM UTC

selfmodruntime wrote: post #97

tialaramex wrote: post #74

Earlier quoted context omitted.

But it isn't different, that's Tony Hoare's Billion Dollar Mistake.

It is different. Handling `None` in a way that crashes your program is well defined in a Rust function. If you're using `unwrap` or `expect`, the program will crash with a stack trace and an error, instead of running into undefined behavior.

While it is undefined behavior on the C standard level it a null pointer dereference is guaranteed to trap on most platforms.