Linux Kernel Rust Code Sees Its First CVE Vulnerability (phoronix.com)
- Reference: 0180412625
- News link: https://it.slashdot.org/story/25/12/17/2034233/linux-kernel-rust-code-sees-its-first-cve-vulnerability
- Source link: https://www.phoronix.com/news/First-Linux-Rust-CVE
> This first CVE ( [3]CVE-2025-68260 ) for Rust code in the Linux kernel pertains to the Android Binder rewrite in Rust. There is a race condition that can occur due to some noted unsafe Rust code. That code can lead to memory corruption of the previous/next pointers and in turn cause a crash. This CVE for the possible system crash is for Linux 6.18 and newer since the introduction of the Rust Binder driver. At least though it's just a possible system crash and not any more serious system compromise with remote code execution or other more severe issues.
[1] https://social.kernel.org/notice/B1JLrtkxEBazCPQHDM
[2] https://www.phoronix.com/news/First-Linux-Rust-CVE
[3] https://lore.kernel.org/linux-cve-announce/2025121614-CVE-2025-68260-558d@gregkh/T/#u
Rust is NOT memory safe (Score:1, Troll)
It's over, Rust can never claim to be memory safe, it's not a discussion point anymore. The fact you can use a keyword called “unsafe”, makes all the claims, and the religious like devotion, nothing more than a joke. For everyone who was ready to die on the hill of Rust safety, it's over, Rust is another language that has failed the memory safe experiment.
Re: Rust is NOT memory safe (Score:2, Insightful)
And this is tagged "troll."
The truth is that Rust's cheerleaders have been trolling since the beginning about memory safety.
Re: (Score:2)
I don't understand the Rust culture, I really don't. You never see this kind of hardline, ultra-orthodox alignment with other languages, at this scale. I remember Lunduke said something like “GW Basic in certain circumstances could compile faster than Rust.”, then showed it, and got death threats. Here, we have literal memory corruption, and Rust fans are upset, or taking up arms that anyone dare even suggest that Rust might have memory issues? Rust is the language equivalent of far-left fe
Re: (Score:2)
> You never see this kind of hardline, ultra-orthodox alignment with other languages, at this scale.
Tell Python programmers that white-space block delineation is dumb and braces are better. :-)
Re: (Score:2)
You'll have some people get annoyed, or possibly mad, but you will not have groups of people calling for death and extreme violence. I know “harder aligned” C programmers, or, Perl (dear lord), but nothing like Rust. People suggest that Rust might not be the best fit for a project, and look what happens publicly. I've had a tiff with a developer about Perl, but it was civil, Rust devotion isn't civil.
Re: (Score:2)
> Tell Python programmers that white-space block delineation is dumb and braces are better. :-)
The reason people will roll their eyes at you over that is that its an incredibly boring debate that ended 30 years ago. Its pure surface level semantics and it just isn't interesting and tends to suggest people haven't actually spent much time understanding what they are complaining about.
Python has plenty of serious problems. But if what you get hung up on is whitespace, it means you dont know what the serious pro
Rust's claims of memory safety (Score:1)
First, I'm not a Rust programmer, but I am a programmer.
Rust's claims about memory safety read to me like "we promise we are memory-safe except where you tell me they aren't. If you use a library that is marked as unsafe, you are responsible for knowing what you are doing and what the library is doing. But in all other cases, we guarantee memory safety."
If I wanted 100% memory safety, there would be a lot of things that I either couldn't do or couldn't do efficiently enough to be worth doing. A large part
Re: (Score:2)
You could make the same claim about C, it's memory safe, except when it's not. The narrative of Rust was that it's memory safe to a level that the concept of memory based corrupt or memory nonsense is no longer possible. Obviously, that's a ridiculous claim to make, but so many people believed it, to the point they were willing to commit violence against anyone who dared question the divine nature of Rust memory safety. Lunduke has proven that, he gets death threats when he makes objectively true, and har
Re: (Score:3)
We need to remove seatbelts from cars, they are useless because people can drive without wearing them. Why did we even have seatbelts. All those people claiming seatbelts are of any benefit are just religious and nothing more than a joke.
Yes this is how stupid your post sounds.
Re: (Score:2)
Except that no one claims seat belts prevents accidents, and with Rust people do claim Rust prevents any possibility of an error, or memory corruption. That's why this needs to be called out, the pure stupidity of the hardcore Rust or die group. The group that calls for death and extreme violence against people who simply suggest that Rust might not be the greatest created language of all time, and who doubt the stated claims of pure and absolute safety. You can prove this, just watch video from Lunduke,
No Joy in Mudville-err Rust Language Army (Score:2)
Well, the the Rust Army has, who has had their eyes set on the Linux use-case prize, has suffered a setback.
experniment (Score:2)
_NOW_ the experiment is over.
re-write (Score:3)
> CVE ... pertains to the Android Binder rewrite in Rust.
Rewrites always carry the risk of new problems as well as old problems in new ways.
Just curious; was there a reason this coded needed to be rewritten or was it a failure to apply "if it's not broke, don't fix it?"
Big Yawn Here (Score:2)
A vulnerability in an unsafe section of Rust is not surprising, and it was essentially inevitable that it would happen. That's the whole point of having safe vs unsafe modes.
There are still two really good reasons to use Rust widely:
Safe sections are typically the majority of the code, and they avoid problems without requiring and agonizing level of developer scrutiny and testing.
The requirement to mark unsafe sections makes it easier to identify problems and fix them. The maintainer probably knows exactly
Nope (Score:5, Funny)
I don't believe it. I've been repeatedly told that Rust code is memory safe and this sort of stupid programming error can't happen in Rust, only other languages.
Re: (Score:3, Insightful)
it was in an 'unsafe' section for what it is worth.
But then systems programing means you're going to have a lot of that. So maybe rust really isn't such a good systems language... as it does not really get you much when you can't use its safety features.
Re: (Score:2)
I never tried or looked into Rust. Can you explain to me what is 'unsafe' section is and how necessary is it? Is the issue that Rust checks were intentionally subverted by some idiot or is that Rust is not usable/cannot accomplish what you need to do in most cases and you have to use 'unsafe' section?
Re: Nope (Score:2)
Unsafe is very hard to avoid in Rust. It's pretty much impossible for something low level like kernel development. 20% of Rust packages use unsafe. And most Rust apps depend on multiple packages.
Re: Nope (Score:4, Insightful)
So, in other words, it really isn't any better at bare metal development than C/C++. If you have to direct memory and hardware manipulation in unsafe blocks, then really, it's just the same thing as doing it in C.
Re: (Score:3)
The applicable bit here is that the rust compiler enforces memory ownership rules that ought to prevent multiple threads from modifying the same memory address. By using an "unsafe" block of code, you've told the compiler to turn those rules off.
I can't comment on how necessary an "unsafe" block would be in this instance, but I would guess that systems programming definitely requires unsafe blocks at times.
Re: (Score:2)
> The applicable bit here is that the rust compiler enforces memory ownership rules that ought to prevent multiple threads from modifying the same memory address. By using an "unsafe" block of code, you've told the compiler to turn those rules off.
At which point, you're (basically) using C - again. Not saying that there's no benefit to Rust and its safe(er) sections, but being a good Rust programmer doesn't make you a good C programmer, which (I'm guessing) is what you need more of for the unsafe sections. Rewriting things in Rust for the sake of it probably hinges on the ratio or safe to unsafe code, where those are and how they're maintained.
Re: Nope (Score:4, Informative)
> The applicable bit here is that the rust compiler enforces memory ownership rules that ought to prevent multiple threads from modifying the same memory address. By using an "unsafe" block of code, you've told the compiler to turn those rules off.
This is incorrect, unsafe rust doesn't allow you to simply ignore the borrow checker. This is a very common myth, usually stated by C++ developers who already love footguns and poo-poo the language despite never having used it. In rust, ownership rules are ALWAYS enforced no matter what you do. In fact, there are exactly 5 things that unsafe allows:
[1]https://doc.rust-lang.org/book... [rust-lang.org]
You can, in principle, circumvent the borrow checker by converting a normal pointer into a raw pointer and later dereferencing it, which is just adding indirection. But in practice, there's no good reason to do this, and there's likely already an easier way to do what you might be wanting to do with it that doesn't require unsafe. Raw pointers are generally only really useful for FFI, which is already inherently unsafe in any language.
[1] https://doc.rust-lang.org/book/ch20-01-unsafe-rust.html
Re: (Score:2)
Portions of the Rust code can be marked as "unsafe". Within an unsafe block you can dereference a raw pointer and call an unsafe function (e.g. an external C function). Outside of the unsafe, the compiler guarantees memory safety and absence of data races, during compilation. Unsafe blocks are necessary to interact with the hardware, call external libraries written in other languages or write a highly optimized or specialized code.
While the entire application written in C (and C++) is inherently unsafe by
Re: (Score:2)
Thank you for clear explanation.
Re: (Score:3)
C code is also quite safe and easy to write in a memory safe way if you don't use pointers. Every language has the ability to shoot yourself in the foot with its more complex functionality. For rust, you need to specifically declare functions or types "unsafe" in order to do so. It opens the possibility to do things that the compiler can't verify to be memory safe. But you need to do it explicitly.
Re: (Score:2)
This CVE is discussed in detail by this YTer. He's a Rust proponent but very open about its limitations.
[1]https://www.youtube.com/watch?... [youtube.com]
[1] https://www.youtube.com/watch?v=dgPI7NfKCiQ
Re: (Score:2)
> I don't believe it. I've been repeatedly told that Rust code is memory safe and this sort of stupid programming error can't happen in Rust, only other languages.
That's your own ignorance at work. Rust is memory safe, if you use it that way. TFS specifically not it was in an explicitly *unsafe* code. I.e. the programmer literally has to type the word "unsafe" into the code.
Even people who we put into rooms with walls made of fluffy pillows for their own protection, could none the less if they tried, suffocate themselves.
Re: (Score:2)
So you're retarded?