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

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

#21

Post by bbippin » Mon, Jun 15, 2026, 5:50 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... )

The point is that memory issues are a smallish number of issue compared to the larger ecosystem of vulnerabilities, and choosing to port everything to Rust is like over-optimizing. Well, that’s my 2 cents.

For a language as ugly as Rust, my thought is that people should actually be using Ada, and have a mathematically provable correctness angle; not just a replacement for C/C++ with memory safety.

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

#22

Post by [deleted] » Mon, Jun 15, 2026, 5:51 PM UTC

shevy-java wrote: post #15

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…

[deleted]

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

#23

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

bbippin wrote: post #21

khuey wrote: post #12

Earlier quoted context omitted.

> 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... )

The point is that memory issues are a smallish number of issue compared to the larger ecosystem of vulnerabilities, and choosing to port everything to Rust is like over-optimizing. Well, that’s my 2 cents. For a language as ugly as Rust, my thought is that people should actually be using Ada, and have a mathematically provable correctness angle; not just a replacement for C/C++ with memory safety.

> The point is that memory issues are a smallish number of issue compared to the larger ecosystem of vulnerabilities

If memory safety issues are 75% of exploited zero days it sounds to me like they're the biggest issue in the ecosystem by far.

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

#24

Post by ghosty141 » Mon, Jun 15, 2026, 5:53 PM UTC

shevy-java wrote: post #15

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…

> but Rust is pushing into domains where C and C++ dominated in the past.

I think it's also a big sign that the linux kernel adopted rust and not c++. (only for small parts but still)

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

#25

Post by sunshowers » Mon, Jun 15, 2026, 5:53 PM UTC

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…

If you are interested in a more nuanced take on what makes unsafe Rust both valuable and difficult, check out my blog post on the Oxide blog: https://oxide.computer/blog/iddqd-unsafe

I directly tackle the concerns you mentioned, and as a followup I'm actually working on formally verifying the library as well (I've had some success and will publish an update regarding this).

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

#26

Post by afdbcreid » Mon, Jun 15, 2026, 5:54 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... )

My understanding is that they claim that the average Joe writes code in a garbage-collected memory-safe language.

Which is... true? but irrelevant. Such applications are not suggested to be ported to Rust. Of course, some people still do that, because they like Rust; but that's their personal choice.

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

#27

Post by lawn » Mon, Jun 15, 2026, 5:54 PM UTC

slopinthebag wrote: post #6

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…

Any sources for these numbers?

90℅ of all statistics is made up.

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

#28

Post by rumblefrog » Mon, Jun 15, 2026, 5:55 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]

Little hostile with the refutal

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

#29

Post by cesaref » Mon, Jun 15, 2026, 5:56 PM UTC

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 totally possible in C to produce good looking but actually invalid arguments that can't be spotted at runtime without UB (out of bounds access etc).

Edit: Actually thinking about this more, I guess the problem is that you are likely linking against a release library implementation, so it's not possible to add a precondition without introducing a runtime overhead, which is probably more likely what we are talking about with this case.

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

#30

Post by 360MustangScope » Mon, Jun 15, 2026, 5:57 PM UTC

shevy-java wrote: post #15

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…

I agree about Rust gaining ground but using the argument that it got 10% faster due to Rust is not really that useful.

If they rewrote it in C++ again, they would have most likely got the same result because they got a chance to fix a design that might not have been most optimal.