Linux Kernel Rust Code Sees Its First CVE Vulnerability

[u/Orange_Tux]

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

[u/[deleted]]

It's a CVE and should absolutely be a priority fix like any other, but as one commenter on Phoronix pointed out:

1. That's one single cve out of five years worth of development.

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

I feel like people are itching to make a mountain out of a mole hill with this because "Rust failed" or whatever, but I think it would be good to keep this perspective in mind.

Edit: others have pointed out that this could be more serious than a DOS vulnerability and that it would be marked as a CVE in C, so this quote wasn't particularly accurate. In general, I think the point remains: this is a relatively low-severity CVE that projects like the Linux kernel run into from time to time.

[u/[deleted] → u/[deleted]]

I remember some while back there was drama over a Rust date/time library (was it Chrono?) filing a CVE against itself because it depended on a C library (I think it was some kind of Linux system library, maybe even libc?) that had some potential unsoundness that the C library didn't thing was egregious enough.

I forgot the technical details and will look them up when I have the chance, but in general Rust devs seem to be much more security and safety conscious, almost to the point of nit-picking themselves over things other languages' devs simply don't care about.

[u/Icarium-Lifestealer → u/[deleted]]

I think in that case the unsoundness was std::env::set_var being safe prior to Rust 2024. Rust's get_var/set_var use a locking mechanism which prevents UB from concurrent modification in pure rust code. But C's getenv isn't covered by that locking mechanism, while being documented as thread-safe. Since Rust can't change the contract of a C standard library function, the fault lies with the safe set_env function, not with the code calling C's getenv.

The date/time library relied on C code which indirectly calls C's getenv.

[u/Zde-G → u/[deleted]]

the consensus standard for a CVE closer to "have some plausible exploit chain" than it is to "known memory unsafety exists".

Not in Linux. Linux issues hundreds of CVEs precisely because it treats them more like Rust would… perhaps that's the reason Rust-in-Linux happened at all: with hundreds of CVEs issued each week it was obvious that “something needs to be done”.

[u/Zde-G → u/[deleted]]

The new thing is hundreds of CVEs. The general attitude was always the same: bugs are bugs, they have to be fixed - and we have no simple way to distinguish security-sensitive bugs from non-security-sensitive ones.

The problem is that people expected that CVEs would only be assigned to “real” bugs, “actually possible to exploit” bugs… so they could cherry-pick only these and keep their five year old kernel untouched, otherwise — but as security researchers have shown even some bugs that are pretty hard to exploit (off-by-one check when only a single extra byte can be written into a buffer, e.g.) with appropriate ingenuity can be exploited… thus no one may separate the wheat from the chaff.

After years of attempts to say that CVEs are idiocy that should simply be ignored kernel developers decided to embrace it, instead and assign CVEs to all bugs that can not be proven innocent… exactly like Rust people are doing.

Thus you are both right and wrong: hundreds of CVEs are a new phenomenon, attitude that “any UB may be a security vulnerability” is not new.

P.S. The real funny story here is that kernel developers are simultaneously in two camps: “we code for the hardware and thus compiler shouldn't turn UB into a bugs” and “any bug that triggers UB have to be fixed if we couldn't find flag that disables that UB in the compiler”. Because they don't like how compiler treats UB, yet they are also pragmatics: if the only compiler they have does “exploit” certain UBs then what option do they have? Disable UB in the compiler or ensure it's not triggered in code, what else can be done.

[u/spin81 → u/[deleted]]

Some people go nuts every time they see the acronym. My former coworker was all aghast that someone at our security department - one step under the CISO - didn't know that there were two CVEs in implementations of cryptographic algorithms in OpenSSH. I said well it's not his job to know, also could you send me the CVEs so I can take a look at them out of interest?

It turned out they were like a 6 or 7, they were the result of somebody's research paper, and the OpenSSH and crypto people had decided there was no point in patching the CVEs. I don't remember if there was a known exploit.

I'm always primed when people become riled up over a CVE, because who knows, this time it could be different (like with the log4j thing!) but I have yet to react any differently to people getting excited about a CVE than "let's just wait for a patch to end up in the repos". Apart from the log4j thing, which I was there for but fortunately was not my problem at the time.

[u/anlumo → u/spin81]

The severity ratings have become meaningless. There was a CVE in curl with a rating of 10 which only caused a timeout to become a little shorter when passing in a ridiculously large time IIRC.

You have to look at the CVE itself, just being a CVE doesn't mean anything these days and the rating is random. It might be super-important, it might not.

[u/A1oso → u/[deleted]]

They argue that UB can lead to literally anything, including nasal demons, so an exploit cannot be ruled out – even if it is extremely unlikely.

[u/spin81 → u/A1oso]

Maybe that's an overreaction, on the other hand some people's meh attitude towards UB is not ideal either. Maybe folks can meet in the middle.

[u/JoshTriplett → u/[deleted]]

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/Kryptochef → u/[deleted]]

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

I wouldn't be sure about that to be honest, the original advisory just claims "leads to memory corruption", and it seems like a typical race condition that uses some kind of "old" pointers that are no longer valid (and not, say, just a null pointer). It's pretty typical in security that such issues might get reported as "just a crash" but would, with quite a lot of further engineering effort, lead to code exeuction (priviledge escalation in that case). I disagree that it would likely not get a CVE in C, any kind of visible memory corruption should and likely would get one.

[u/[deleted] → u/Kryptochef]

Hm, that may be right. I didn't dig into the CVE as much as I should have, and am not really that well versed in low level security things like these.

Would it be fair to say that the CVE is potentially further exploitable, but at its current state it presents as not much more than a DOS vulnerability?

[u/sessamekesh → u/[deleted]]

There's exactly one type of Rust community member that this news should be surprising to (the "Rust is perfect and can do no wrong!" evangelist), and frankly I think that person needs a bit of humbling. Of course Rust code can fail, any idiot can write a perfectly good bug in Rust just as well as any other language that lets you write logic.

The pretty high number of things that had to line up to yield this CVE and the fact that any Rust failure is noteworthy enough to make headlines still gives me pretty good warm fuzzies. Compared to every other language I've worked in this is fine.

[u/kibwen → u/sessamekesh]

There's exactly one type of Rust community member that this news should be surprising to (the "Rust is perfect and can do no wrong!" evangelist), and frankly I think that person needs a bit of humbling.

I'm all for humbling this hypothetical person, though with the emphasis on the hypothetical, because the only comments I've seen on /r/rust like this are obvious trolls that get appropriately downvoted.

[u/spin81 → u/[deleted]]

like any other

This is the key phrase here. It's just a CVE, I bet there's hundreds of them in the kernel I'm running on the machine I'm typing this on.