5 ms·

> And a few days ago a security vulnerability was found in the Rust Linux kernel code. was it a security vulnerability? I'm pretty sure it was "just" a crash.

by rtpg 10mo ago

> And a few days ago a security vulnerability was found in the Rust Linux kernel code. was it a security vulnerability? I'm pretty sure it was "just" a crash. Though maybe someone smarter than me could have turned that into something more. I have no dog in this race, I really like the idea of Rust drivers but can very much understand retiscience at getting Rust to be handling more core parts of the kernel, just because Rust's value seems to pay off way more in higher level code where you have these invariants to maintain across large code paths (meanwhile writing a bunch of doubly-linked lists in unsafe Rust seems a bit like busy work, modulo the niceties Rust itself can give you)

taneliv 10mo 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 https://www.cve.org/CVERecord/?id=CVE-2025-68260 [2] https://lore.kernel.org/linux-cve-announce/2025121614-CVE-2025-68260-558d@gregkh/T/#u https://lore.kernel.org/linux-cve-announce/2025121614-CVE-20...
- uecker 10mo 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 10mo 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.
    - uecker 10mo ago
      There were certainly a lot of people running around claiming that "Rust eliminates the whole class of memory safety bugs." Of course, not everybody made such claims, but some did. Whether it is "significantly easier" to manage these types of problems and at what cost remains to be seen. I do not understand you comment about "confirmation bias" as did not make a quantitative prediction that could have bias.
      - ivanbakel 10mo ago
        > There were certainly a lot of people running around claiming that "Rust eliminates the whole class of memory safety bugs." Safe Rust does do this. Dropping into unsafe Rust is the prerogative of the programmer who wants to take on the burden of preventing bugs themselves. Part of the technique of Rust programming is minimising the unsafe part so memory errors are eliminated as much as possible. If the kernel could be written in 100% safe Rust, then any memory error would be a compiler bug.
        uecker 10mo ago
        Yes, but this is the marketing bullshit I am calling out. "Safe Rust" != "Rust" and it is not "Safe Rust" which is competing with C it is "Rust".
        simonask 10mo ago
        This is just so obtuse. Be serious. Even if you somehow manage to ignore the very obvious theoretical argument why it works, the amount of quantitative evidence at this point is staggering: Rust, including unsafe warts and all, substantially improve the ability of any competent team to deliver working software. By a huge margin. This is the programming equivalent of vaccine denialism.
- chironjit 10mo 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 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
yourdetect 10mo ago
[flagged]

by rtpg 10mo ago

taneliv 10mo 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 https://www.cve.org/CVERecord/?id=CVE-2025-68260 [2] https://lore.kernel.org/linux-cve-announce/2025121614-CVE-2025-68260-558d@gregkh/T/#u https://lore.kernel.org/linux-cve-announce/2025121614-CVE-20...

uecker 10mo 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 10mo 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.
  - uecker 10mo ago
    There were certainly a lot of people running around claiming that "Rust eliminates the whole class of memory safety bugs." Of course, not everybody made such claims, but some did. Whether it is "significantly easier" to manage these types of problems and at what cost remains to be seen. I do not understand you comment about "confirmation bias" as did not make a quantitative prediction that could have bias.
    - ivanbakel 10mo ago
      > There were certainly a lot of people running around claiming that "Rust eliminates the whole class of memory safety bugs." Safe Rust does do this. Dropping into unsafe Rust is the prerogative of the programmer who wants to take on the burden of preventing bugs themselves. Part of the technique of Rust programming is minimising the unsafe part so memory errors are eliminated as much as possible. If the kernel could be written in 100% safe Rust, then any memory error would be a compiler bug.
      - uecker 10mo ago
        Yes, but this is the marketing bullshit I am calling out. "Safe Rust" != "Rust" and it is not "Safe Rust" which is competing with C it is "Rust".
        simonask 10mo ago
        This is just so obtuse. Be serious. Even if you somehow manage to ignore the very obvious theoretical argument why it works, the amount of quantitative evidence at this point is staggering: Rust, including unsafe warts and all, substantially improve the ability of any competent team to deliver working software. By a huge margin. This is the programming equivalent of vaccine denialism.
chironjit 10mo 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 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

yourdetect 10mo ago

[flagged]