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

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

#11

Post by afdbcreid » Mon, Jun 15, 2026, 5:40 PM UTC

kllrnohj wrote: post #5

chilljinx wrote: post #3

Unsafe is not necessary to trigger UB in case no_std is used. Nor if one of the soundness holes in the Rust programming language itself is encountered. Nor if there is UB in one of the libraries used as a dependency by the library you are using. Nor if there is UB in the Rust standard library. Which has happened many times, since the Rust standard library is full of unsafe. Rust also requires libraries to be safe reg…

> Nor if one of the soundness holes in the Rust programming language itself is encountered. imo one of those soundness holes is caused directly from trying to prevent UB - integer overflows. It is inconsistent in Rust what happens in that scenario depending on compiler flags, which basically just makes it UB for any given piece of code. And, unfortunately, default release mode behavior is unsafe.

You seem to have been misinformed. Rust panics on overflow in debug mode (or always if you toggle a compiler flag), and has a guaranteed wrap-around in release mode. In no case there is UB.

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

#12

Post by khuey » Mon, Jun 15, 2026, 5:40 PM UTC

jurschreuder wrote: post #4

Just want to remind everyone that only 1% of vulnerabilities are memory related in the average Joe's code. And only 20% of memory related bugs are use-after-free which the borrow checker fighting is for. And 100% of the use-after-free exploits were to gain admin rights on an already hacked Windows (all windows) computer. So for the vast majority of people the borrow checker adds nothing. The vast majority of memory s…

> Just want to remind everyone that only 1% of vulnerabilities are memory related in the average Joe's code.

Unless your point is merely that average Joes write such terrible code that you don't even need memory safety issues to exploit their software, [citation needed]

Google says memory safety issues are 75% of exploited zero days. (https://security.googleblog.com/2024/10/safer-with-google-ad...)

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

#13

Post by chilljinx » Mon, Jun 15, 2026, 5:42 PM UTC

jurschreuder wrote: post #4

Just want to remind everyone that only 1% of vulnerabilities are memory related in the average Joe's code. And only 20% of memory related bugs are use-after-free which the borrow checker fighting is for. And 100% of the use-after-free exploits were to gain admin rights on an already hacked Windows (all windows) computer. So for the vast majority of people the borrow checker adds nothing. The vast majority of memory s…

I do not believe that I agree, and I am not sure about all of your numbers.

The borrow checker does add something, but it definitely costs something as well in multiple ways, also in terms of how it is done in Rust and at a programming language design perspective.

It would be very funny if you were batting for Rust, and just having a laugh at others here.

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

#14

Post by chilljinx » Mon, Jun 15, 2026, 5:44 PM UTC

afdbcreid wrote: post #9

chilljinx wrote: post #3

Unsafe is not necessary to trigger UB in case no_std is used. Nor if one of the soundness holes in the Rust programming language itself is encountered. Nor if there is UB in one of the libraries used as a dependency by the library you are using. Nor if there is UB in the Rust standard library. Which has happened many times, since the Rust standard library is full of unsafe. Rust also requires libraries to be safe reg…

> Unsafe is not necessary to trigger UB in case no_std is used I have no idea what are you talking about, no_std is just completely irrelevant here. > Nor if one of the soundness holes in the Rust programming language itself is encountered Have you actually examined those soundness holes? It is basically impossible to hit them without writing code which is meant to hit them. And this is also noted in a footnote. > No…

[flagged]

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

#15

Post by shevy-java » Mon, Jun 15, 2026, 5:44 PM UTC

C and C++ are kind of losing out to Rust right now.

Take ladybird (last month blog; not that ladybird stands for all projects out there, of course; it is just an example):

https://ladybird.org/newsletter/2026-05-31/

"The HTML parser is now written in Rust" "The Rust parser is also about 10% faster than the C++ version it replaced,"

I am not saying this is a systematic analysis by far, but Rust is pushing into domains where C and C++ dominated in the past. And that seems to be a real push. To me it looks as if both C and C++ are standing to lose some ground in the next few years, directly to Rust. Perhaps even via snowball effect.

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

#16

Post by jeffbee » Mon, Jun 15, 2026, 5:44 PM UTC

jurschreuder wrote: post #4

Just want to remind everyone that only 1% of vulnerabilities are memory related in the average Joe's code. And only 20% of memory related bugs are use-after-free which the borrow checker fighting is for. And 100% of the use-after-free exploits were to gain admin rights on an already hacked Windows (all windows) computer. So for the vast majority of people the borrow checker adds nothing. The vast majority of memory s…

Hrmm. I don't think there exists a set of compiler flags that will just make an existing C++ (or, worse, a mixed C and C++) project safe to the extent that you suggested. The STL hardening flags don't help for ordinary arrays that aren't accessed via smart pointers, and they don't help code that uses a pointer+offset style of access. As for UAF, nothing in C++ comprehensively prevents you from accessing an invalid stored reference even if you have cranked up the hardening mode to DEBUG. Rust, on the other hand, affirmatively prevents that.

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

#17

Post by chilljinx » Mon, Jun 15, 2026, 5:46 PM UTC

Groxx wrote: post #10

chilljinx wrote: post #3

Unsafe is not necessary to trigger UB in case no_std is used. Nor if one of the soundness holes in the Rust programming language itself is encountered. Nor if there is UB in one of the libraries used as a dependency by the library you are using. Nor if there is UB in the Rust standard library. Which has happened many times, since the Rust standard library is full of unsafe. Rust also requires libraries to be safe reg…

I'm caught somewhere between interpreting this as "C is all we need. git gud" and "rust hurt me and I'm still mad" and I'm struggling to see any other option. It's an unfocused rant that seems keyed off "rust" and little else. In broad strokes it's correct, this stuff happens and it's hard to be correct all the time. But are you trying to make a point? Or just ranting? Also that linked issue was considered a CVE and…

[flagged]

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

#18

Post by afdbcreid » Mon, Jun 15, 2026, 5:47 PM UTC

chilljinx wrote: post #14

afdbcreid wrote: post #9

Earlier quoted context omitted.

> Unsafe is not necessary to trigger UB in case no_std is used I have no idea what are you talking about, no_std is just completely irrelevant here. > Nor if one of the soundness holes in the Rust programming language itself is encountered Have you actually examined those soundness holes? It is basically impossible to hit them without writing code which is meant to hit them. And this is also noted in a footnote. > No…

[flagged]

What? Absolutely not. May you explain why no_std is relevant?

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

#19

Post by pitaj » Mon, Jun 15, 2026, 5:47 PM UTC

chilljinx wrote: post #14

afdbcreid wrote: post #9

Earlier quoted context omitted.

> Unsafe is not necessary to trigger UB in case no_std is used I have no idea what are you talking about, no_std is just completely irrelevant here. > Nor if one of the soundness holes in the Rust programming language itself is encountered Have you actually examined those soundness holes? It is basically impossible to hit them without writing code which is meant to hit them. And this is also noted in a footnote. > No…

[flagged]

Explain how it is relevant

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

#20

Post by kalaksi » Mon, Jun 15, 2026, 5:49 PM UTC

khuey wrote: post #12

jurschreuder wrote: post #4

Just want to remind everyone that only 1% of vulnerabilities are memory related in the average Joe's code. And only 20% of memory related bugs are use-after-free which the borrow checker fighting is for. And 100% of the use-after-free exploits were to gain admin rights on an already hacked Windows (all windows) computer. So for the vast majority of people the borrow checker adds nothing. The vast majority of memory s…

> Just want to remind everyone that only 1% of vulnerabilities are memory related in the average Joe's code. Unless your point is merely that average Joes write such terrible code that you don't even need memory safety issues to exploit their software, [citation needed] Google says memory safety issues are 75% of exploited zero days. ( https://security.googleblog.com/2024/10/safer-with-google-ad... )

And at least in Chromium project, half of those memory safety issues are use-after-free: https://www.chromium.org/Home/chromium-security/memory-safet...