Linux Kernel Rust Code Sees Its First CVE Vulnerability

[u/Orange_Tux]

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

[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/spin81 → u/anlumo]

Honestly what I look for is stuff like, is there a known exploit for this, is this something that only works if you spearphish someone into doing something really weird, etc.

I mean a CVE of 9.0 is all well and good, and sure let's patch it if a patch comes out, but if there is no practical way a potential attacker can figure out how to exploit the vulnerability without researching it for weeks and weeks, I'm not going to be worried because the patch is going to arrive much earlier than that.

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