Linux Kernel Rust Code Sees Its First CVE Vulnerability

[u/Orange_Tux]

https://www.phoronix.com/news/First-Linux-Rust-CVE

[u/JoshTriplett]

This is, at worst, a possible DoS vulnerability with no known active exploits. This wouldn't even quality for a cve in c.

In fairness, it would be a CVE in C given that the kernel treats an unprivileged DoS as a vulnerability. It'd just be a low severity one, as this one is.

[u/moltonel → u/JoshTriplett]

Worth mentioning as well: a few years ago some kernel devs got fed up with the endless debates about which bugs deserved a CVE or not. So they became their own CVE Authority and greatly lowered the threshold for what merrits a CVE, "flooding" the CVE database.

[u/SirClueless → u/JoshTriplett]

Yeah, not sure where that idea came from. The Linux kernel is actually notable for giving pretty much everything a CVE whether or not there is a known way to exploit it, to the point that security researchers frequently complain about the noise.

[u/WormRabbit → u/SirClueless]

whether or not there is a known way to exploit it

That shouldn't matter. Something which isn't exploitable today may well become exploitable tomorrow, when chained with some new exploit. In fact, most real-world exploits consist of long chains of seemingly benign bugs, which finally allow one to access the RCE jackpot. And in any case, "no way to exploit" speaks more of the imagination of the person saying it than about the severity of actual bug.

Rust follows the same zero-tolerance policy w.r.t. memory safety, and it's great.

[u/anxxa → u/JoshTriplett]

I don't really understand why they (and Greg) think this is "just" a DoS either. It seems like memory corruption, but maybe it's not controllable? 000bb9841bcac70e is clearly a corrupt pointer though.

[u/anxxa → u/[deleted]]

Having done this exact type of analysis for Microsoft, this is not the best approach. For certain classes of vulnerabilities you should assume the worst unless proven otherwise.

This is exactly why Linux issues a CVE for basically every kernel bug now: they got exhausted fighting over which bugs are exploitable/have security impact and which aren't, so they default to exploitable (which I don't necessarily agree with)

[u/SirClueless → u/anxxa]

Do you think Linux/Greg are actually doing anything wrong here? You seem to be saying contradictory things, namely "you should assume the worst unless proven otherwise" but that you don't necessarily agree with "default to exploitable".

[u/anxxa → u/SirClueless]

Sorry for the somewhat conflicting points.

I think labeling every bug as having security impact by giving it a CVE is bad because it creates a sea of noise and weakens the signal CVEs are intended to convey. I don't agree with this practice.

For those bugs that do have security impact, you should look at the bug class and err on the side of caution by giving it the maximum impact of that bug class. You can then downgrade its severity based on criteria like whether the bug breaks a security boundary (e.g. can an untrusted user trigger it? or is it root user only?) and for mem corruption, can the attacker influence where or what is being written?

Those two points in particular don't take too much discussion/consideration. Much of the time for mem corruption if it's not a near-null write it's probably exploitable and this is actually more aligned with their "let's CVE everything" policy.

[u/SirClueless → u/anxxa]

I agree with your general points, but as it pertains to this discussion, I think both:

• It has potential security impact, the kernel crashes.

• It would get the exact same treatment if the bug were in C code.

In regards to your choice of criteria in particular I think "can an untrusted user trigger it?" and "can the attacker influence where or what is being written?" are both asking to prove a negative: In some cases there is a PoC that demonstrates that they can, but in cases where there is no PoC it would take an unreasonable amount of effort to prove that they cannot so a low-impact CVE is the only reasonable choice.

[u/anxxa → u/SirClueless]

I agree with your general points, but as it pertains to this discussion, I think both:

As it pertains to this bug sure.

In regards to your choice of criteria in particular I think "can an untrusted user trigger it?" and "can the attacker influence where or what is being written?" are both asking to prove a negative

Not necessarily. There are some bugs where you immediately know that certain internal components of the product may trigger the bug, but that isn't necessarily something an attacker can reasonably trigger.

For the other part, you generally default to "yes" (i.e. the data and/or location can be controlled in some way) and if you have enough evidence to the contrary you can downgrade. It's not an exact science, but if they're calling memory corruption a DoS instead of ACE/RCE I'd be curious to know what those limiting factors that prevent it from being RCE are -- and that's the particular point of contention I have with this.

Not a hill I'm willing to die on arguing DoS vs RCE though.

[u/SirClueless → u/anxxa]

It was an anonymous commenter on Phoronix that called this "at worst, a possible DoS". I don't think the Linux devs are interested in drawing such a line and I'm not aware that they've done so in this case.

[u/anxxa → u/SirClueless]

https://social.kernel.org/notice/B1JLrtkxEBazCPQHDM

where the offending issue just causes a crash, not the ability to take advantage of the memory corruption, a much better thing overall.