top | item 46323213

(no title)

taneliv | 2 months ago

> was it a security vulnerability? I'm pretty sure it was "just" a crash.

It's a race condition resulting in memory corruption.[1][2] That corruption is shown to result in a crash. I don't think the implication is that it can result only in crashes, but this is not mentioned in the CVE.

Whether it is a vulnerability that an attacker can crash a system depends on your security model, I guess. In general it is not expected to happen and it stops other software from running, and can be controlled by entities or software who should not have that level of control, so it's considered a vulnerability.

[1] https://www.cve.org/CVERecord/?id=CVE-2025-68260 [2] https://lore.kernel.org/linux-cve-announce/2025121614-CVE-20...

discuss

order

uecker|2 months ago

It is entertaining to observe that how - after the bullshit and propaganda phase - Rust now slowly enters reality and the excuses for problems that did not magically disappear are now exactly the same as what we saw before from C programmers and which Rust proponents would have completely dismissed as unacceptable in the past ("this CVE is not exploitable", "all programmers make mistakes", "unwrap should never been used in production", "this really is an example how fantastic Rust is").

simonask|2 months ago

You have a wild amount of confirmation bias going on here, though.

Of course, this bug was in an `unsafe` block, which is exactly what you would expect given Rust's promises.

The promise of Rust was never that it is magical. The promise is that it is significantly easier to manage these types of problems.

dwattttt|2 months ago

Is it any more or less amusimg, or perhaps tedious, watching the first Rust Linux kernel CVE be pounced on as evidence that "problems .. did not magically disappear"?

Does anyone involved in any of this work believe that a CVE in an unsafe block could not happen?

chironjit|2 months ago

In case anyone is keen for an explanation of the vulnerability, LowLevelTV has done a video on this:

https://youtu.be/dgPI7NfKCiQ?si=BVBQ0MxuDpsbCvOk

The TLDR is that this race condition happened with unsafe code, which was needed to interact with existing C code. This was not a vulnerability with Rust's model.

That said, you can absolutely use bad coding practices in Rust that can cause issues, even for a regular programmer.

Using unwrap without dealing with all return cases is one example. Of course, there is a right way to dealing with return methods, but it's up to the programmer to follow it