The page itself literally leads with multiple extensive statements about how the sqlite CVEs are exaggerated and inaccurate:
> Grey-hat hackers are rewarded based on the number and severity of CVEs that they write. This results in a proliferation of CVEs that have minor impact, or no impact at all, but which make exaggerated impact claims.
Also how most CVEs require arbitrary SQL injection (and if you have this access, you're screwed already):
> Almost all CVEs written against SQLite require the ability to inject and run arbitrary SQL.
It also explains that:
> Few real-world applications meet either of these preconditions, and hence few real-world applications are vulnerable, even if they use older and unpatched versions of SQLite.
---
It also explains that many CVEs are denial-of-service due to division-by-zero, which in Rust can only be caught by using the opt-in `checked_div` so would be equally safe in C and Rust(?)
The CVE is correct that the “gmon” component of the GNU C Library contains memory corruption bugs. In fact, I’ve found even more than the specific one that CVE is about.
But, the claim that this is a security vulnerability is a bit silly. These are profiler functions, which are usually only called in non-production builds with profiling enabled (gcc -pg), and even then only from CRT startup code. It is rather unlikely an attacker can exploit any of these bugs in them without already having the ability to run arbitrary code in the process, at which point they don’t need these functions, they’ve already got all these bugs have to give them.
Yeah, this kind of thing is tricky. Rust has had some CVEs filed against the standard library that are CVEs because of Rust's guarantees. Same issues existed in the C++ standard library but since it's UB, not a CVE there.
All I'm saying is that the CVE process is a human one, with lots of nuance. You're pointing out one aspect of that, that some CVEs are very practical, and others are more theoretical. I was trying to chime in with a similar way in which this is expressed, in that an identical bug in the standard library of one language may be a CVE, while in the other, it may not be a CVE, even with the same problem in both of them. That's "not an issue" in the sense that yeah, of course, Rust cares about this a lot more, so it's a more serious problem in Rust, so this process is legitimate, but it is in the sense that depending on how you're trying to do comparisons, there's more complexity than simply tallying up CVE counts.
CVEs aren’t really anything but an identifier for a problem. It says nothing about its severity, exploitability, or in some cases, whether it is even an actual bug. You can effectively get one for ~free. This is one of the reasons why tallying up their counts is not useful, but others include things like “people focus on some software more”.
With that said, I wouldn’t bring up this distinction here. The problem here is identical but Rust bills itself as a language where it takes responsibility for correctness bugs while C++ is a language where correctness is something that the programmer is supposed to provide. That doesn’t mean the Rust CVE is any less valid or complicated than the other CVE, it’s just that the bug would get assigned to Chromium or IOAccelerator. So if you’re saying that you shouldn’t just look at the number of CVEs and claim that Rust is somehow less secure: yes, absolutely. But if you’re saying this because you want to point out that Rust CVEs are somehow lesser because they are self-imposed, then no, that’s not true.
> Grey-hat hackers are rewarded based on the number and severity of CVEs that they write. This results in a proliferation of CVEs that have minor impact, or no impact at all, but which make exaggerated impact claims.
Also how most CVEs require arbitrary SQL injection (and if you have this access, you're screwed already):
> Almost all CVEs written against SQLite require the ability to inject and run arbitrary SQL.
It also explains that:
> Few real-world applications meet either of these preconditions, and hence few real-world applications are vulnerable, even if they use older and unpatched versions of SQLite.
---
It also explains that many CVEs are denial-of-service due to division-by-zero, which in Rust can only be caught by using the opt-in `checked_div` so would be equally safe in C and Rust(?)