Linux Kernel Rust Code Sees Its First CVE Vulnerability (phoronix.com) 57
Longtime Linux developer Greg Kroah-Hartman announced that the Linux kernel has received its first CVE tied to Rust code. Phoronix reports: This first CVE (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.
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:Nope (Score:5, Interesting)
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:3)
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:5, 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:2)
"...then really, it's just the same thing as doing it in C."
Only worse, because it's not C. Gratuitous change.
Re: Nope (Score:4, Informative)
Indeed. Replacing half a century of collective experience with a new language in an entirely different and far less tested environment to write low level code, where all the memory safety features have to be disabled at all the same failure points where C and assembly have been used... for reasons.
Re: (Score:2)
More specifically it's worse because you can't have multiple references to the same memory location even within a single threaded piece of code. It's like uselessly having one hand tied behind your back.
Re: (Score:2)
Not by a long shot. Unsafe is scoped. 20% of Rust packages may use unsafe, but the amount of code in unsafe sections is far far far lower. Unsafe means "I accept the risk of doing unsafe things" but because it's scoped, just because a package uses Unsafe, it's still benefiting from the memory safety of bounds checking and borrow checking 99% of the time.
That's a far far cry from "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:
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.
Re: (Score:3)
While the entire application written in C (and C++) is inherently unsafe by
Re: (Score:2)
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)
To be fair, C practically insists that you use raw pointers. I think the C standard should allow references. Also some way to handle unique_pointer and shared_pointer. (I mean a way that's standard for the language.) But this would require that the pointer know how large a chunk of memory it was pointing at.
Re: Nope (Score:2)
That kind of defeats the point of what C is intended to do. C is intended as a more of portable assembly. Abstract concepts like references are too much of an abstraction for that. Though C does carry with it some unnecessary and sometimes nasty footguns, like a = b returning the value of b, which some developers do some nutty things with, like the infamous 'if (a = b) {..}' being an intended feature of C. And some developers insist that such footguns are useful and shouldn't ever be removed.
I've heard zig
Re: (Score:2)
And in a single threaded loop it feels like unnecessarily having one hand tied behind your back.
Re: (Score:2)
This CVE is discussed in detail by this YTer. He's a Rust proponent but very open about its limitations.
https://www.youtube.com/watch?... [youtube.com]
Re: (Score:2)
Re: (Score:2)
that a programmer needed to remove a node from a list, realized that it was an inherently unsafe operation, concluded that in that situation it was safe to use unsafe, wrote a "safety" comment explaining why it was the case, proceeded to use unsafe and then inadvertently did this:
- get a lock on some list of pointers
- copy the list
- release the lock
- alter the list
which basically means that no amount of safety guards can really protect us from ourselves. it might also mean that sometimes having those guards
Re: (Score:2)
s/really/fully/
Re: (Score:2)
I don't get the Rust hatred. C has implicitly had an "unsafe" mode for much longer than Rust.
If you're a C kernel developer, you can jump on the Rust bandwagon very easily: just put the keyword unsafe in your comments and you can write code just like Rust developers.
Maybe, just maybe, this mistake was caused by the fact that the same sort of people who are likely to write bugs into their code are the same types of people who prefer "safe" languages because understanding the subtle nuances of how comput
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:1)
So you're retarded?
Re: (Score:2)
It's pretty amateurish to introduce memory vulnerabilities with the "unsafe" keyword when there are perfectly memory safe ways to add memory vulnerabilities to your code (https://github.com/Speykious/cve-rs)
Rust is NOT memory safe (Score:1, Troll)
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)
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)
Re: (Score:2)
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
Re: (Score:2)
The reason people will roll their eyes at you over that is that its an incredibly boring debate that ended 30 years ago.
And yet, you jumped into the argument as if it were fresh dung and you were a dung beetle.
Python has plenty of serious problems. But if what you get hung up on is whitespace,
And there it is, you're a dung beetle white space Python fan who can't resist defending your bad decisions.
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
Swift programmers were worse. It's a crappy language (has all the warts of Objective-C and adds some of its own), but as soon as you say "the enum system makes it easy to write confusing code" you will have all kinds of Swift programmers coming out to insult you and your dog.
Re: (Score:1)
Follow the money.
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)
Re: (Score:2)
Re:Rust is NOT memory safe (Score:4, Insightful)
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)
No Joy in Mudville-err Rust Language Army (Score:2)
experniment (Score:2)
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:
Re: Big Yawn Here (Score:2)
If ain't broken... (Score:2)
Once again we get the proof that rewriting old, working software is a very bad idea.
Key word highlighted for your convenience (Score:1)
This first CVE (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.
what is this rust thing all about, then? (Score:2)
i thought the whole point of integrating rust into linux was precisely for its memory safe features. AND THEN THEY JUST WRITE MEMORY UNSAFE CODE? WHAT THE F*CK!
Re: (Score:2)
You were not told the whole truth and the benevolent dictator Linus also didn't see this coming.
*Grabbing popcorn, waiting for the next Linus rant.
Linux kernel python code (Score:2)
Python would have been a far better choice to be supported in the kernel because it has no pointers.
Those Rust dummies messing it up would be a matter of time.