Linux Kernel Rust Code Sees Its First CVE Vulnerability (phoronix.com) 151
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: Nope (Score:5, Insightful)
"...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:5, Insightful)
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:3, Informative)
where all the memory safety features have to be disabled
This is totally false. Unsafe rust, contrary to common belief by those who haven't used the language, doesn't turn off "all the memory safety" as you just claimed. As noted in one of the links in TFS, the type system continues to be enforced, which also means that pointer lifetimes are enforced by the borrow checker as well. That alone maintains both type safety and temporal safety. Of course, you can defeat temporal safety guarantees with some indirection, but not only is that going to be dead obvious, it'
Re: (Score:3)
Except no one is replacing any collective coding experience. Your comment is stupid on the face of it as that would preclude the inclusion of any new language for any purpose. C wouldn't exist by your own requirement as it was just replacing coding experience that came before it.
In any case no one is talking about C coders who throw out everything to learn Rust. The entire premise of your post is stupid.
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: Nope (Score:2)
Re: (Score:2)
Not sure what you're referring to. I remember when I first started using rust, you couldn't pass variable of a mutable reference to a function and then use an immutable reference later without the borrow checker complaining. Not sure if this is what you mean? Either way, now you don't need to do anything special for it (e.g. no need to manually drop the variable first) as long as you don't try to reuse the variable again.
For me, at least, it's mostly to the point that you don't even think about it.
Re: (Score:2)
Oh one thing I should also add, in case you mean e.g. multithreaded handoff:
Very few reference types aren't Send, namely Cell, RefCell, or Rc. Naturally, if your structs use any of these, they aren't Send either.
Having said that, &T is always Send (and Sync) provided T is Sync. IOW, outside only a handful of cases, you can freely pass ordinary references to other threads. &mut T is a different story, and there are easy and not so easy ways of handling it, depending on how performant you need your co
Re: (Score:3)
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.
How the fuck did you reach that conclusion? Do tell.
Right off the bat I can think of several ways to do not only this but even mutate multiple references. In safe rust.
Like for example https://doc.rust-lang.org/stab... [rust-lang.org]
And of course there's https://doc.rust-lang.org/stab... [rust-lang.org]
And if that's not enough, try from multiple threads too https://doc.rust-lang.org/stab... [rust-lang.org]
Or there's always just...you know...an ordinary reference. Not a raw pointer, like just an ordinary fucking reference. &T is copy. Did I also ment
Re: Nope (Score:2)
That is how it feels at first. But you get used to it. It's like languages with immutable data structures. It seems implausible at first but works okay.
Re: (Score:3)
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:2)
Re: Nope (Score:2)
The benefit is that the unsafe blocks point you to where you should be very careful. The problem is unsafe Rust is worse than C. So, you're really attempting a balancing act where you can use a small amount of unsafe that's generally harder to get right than C, but hopefully that work is minimal compared to all the other parts of the codebase where you don't have to worry about safety and you get other benefits like a robust type system.
Your mileage may vary. I personally wouldn't choose Rust for a kernel o
Re: Nope (Score:2)
Why is unsafe Rust worse than C? There is still a strong type system, integrated macros and low levels of undefined behaviour.
Re: Nope (Score:2)
It's a very common assessment for various reasons. This article does a deep dive into one particularly egregious example.
https://chadaustin.me/2024/10/... [chadaustin.me]
Re: (Score:2)
Thank you, I hadn't seen that before. I did have a good look to see if I could come up with other people saying this and there are a few.
That post seems to boil down to Rust and C having different aliasing rules. I am a little unconvinced at the moment that this is "harder" and not "different" but don't have enough experience to make a judgement for myself.
Re: (Score:2)
While I
Re: Nope (Score:2)
Q.v., my other comment responding to comment's sibling.
Re: (Score:2)
Re: Nope (Score:2)
"It is not perfect therefore it is not better than anything else that exists".
This is how strong your argument is.
I don't use rust, I am certain that people from the rust community can be annoying with certain claims, and I still see that rust can bring significant security improvements over C without being a magical tool that prevents anyone using it from writing any unsafe code.
Re: (Score:2)
Re: (Score:2)
Re: (Score:2)
C and C++ are not the same language. Compared to C, Rust also gives you a ton of useful language stuff that's been developed in the last 60 years or so. This means not writing by hand tons and tons and tons of code you can get the compiler to write for you. That's less code to debug which means fewer bugs.
It also gives you better expressiveness to model the domain in the type system which again leads to shorter, less buggy code which is also more obvious.
Compared to C++: you don't generally IIUC wrap all ru
Re: (Score:2)
And if you're seeing unsafe in packages then most likely it is because that's what they're doing. Even a few unsafe blocks is infinitely preferable to everything being unsafe. As an example I developed a project over 3 year
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: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.
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: (Score:2)
At which point, you're (basically) using C - again.
No, C++.
Rust like C++ has a powerful type system which you can use to enforce a whole bunch of stuff, automate away error prone, repetitive code and so on and so forth.
Re: Nope (Score:5, 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:2)
Like when you are writing buffer overflow exploits and other stuff like that
Which part of it? The exploit itself? Should be pretty easy, just inject a nop sled til you are memory aligned after the final byte of the unchecked buffer. That's nothing more than pure data; an ordinary vec![0u8; N] will do. Or do you mean the first stage? If so, then anything other than handcrafted machine code is doing it wrong. Which is also just data. Or do you mean any later stages? If so, then you're on crack.
Or some lazy developer knows a few shortcuts with nasty pointer arithmetic and figures all they have to do is mark it "unsafe" and carry on.
Why bother when you've got slices and iterators? Show me a case where unsafe rust gives you
Re:Nope (Score:4, Informative)
While the entire application written in C (and C++) is inherently unsafe by design, with Rust you have isolated code blocks, which makes it much easier to review and find any potential bugs.
Official book reference [rust-lang.org]
Re: (Score:2)
Re: (Score:2)
This "entire application written in C (and C++) is inherently unsafe by design" argument is also exaggeration. Not all C code is unsafe, in a single-threaded C application there are essentially three specific features in C that are unsafe with respect to memory namely pointer arithmetic, union access, and free.This also depends on the C implementation, but typically these are the three features you need to care about and you can easily isolate pointer arithmetic and union access into safe wrapper function.
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)
References do protect against dereferences of null pointers, but those trap (or can be made to trap), so are not a memory safety issues. On the other hand, with references code becomes harder to read as
int a = 1; // what is a?
foo(a)
has a clear answer in C but not in C++.
Re: Nope (Score:2)
I don't see any pointer semantics in that. Am I missing something?
Re: (Score:2)
No, and this is the problem. // in C it is clear a is copied and not passed by reference.
void foo(int &);
int a = 1;
foo(a);
Re: (Score:2)
One misconception is that unsafe is throwing away all the safety guarantees that normal Rust provides, but it doesn't. You still
Re: (Score:2)
Re: (Score:2)
And in a single threaded loop it feels like unnecessarily having one hand tied behind your back.
Re: (Score:2)
I specified "single threaded", which is true for most of the code I write, even that used by multi-threaded routines. (It means that a lot of the reference parameters need to be const, but that's minor.)
FWIW, I find even C++ to be annoyingly overprotective in the wrong places. It causes me to need to write multiple copies of the same routine that differ (nearly) only in the parameter specs. E.g. when the looser version would be safe anywhere, but can only be used by routines within the class.
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:3)
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)
Re: (Score:2)
i might be wrong, but afaik all code involved here is rust. that's not the issue, he had to use unsafe, but he should have made sure that the lock was released after he was done with the list, not before. that's not rust's fault, it's the programmer's fault in a situation where the compiler can't help.
Re: (Score:2)
not being picky (i'm learning here), but it seems this is not using a c linked list implementation, but a rust reimplementation of that c kernel equivalent that follows the same design for efficiency reasons, hence the potential for deadlocks.
the fix was just to make the locking more granular, and it turns out that while you can't arbitrariry unlock a resource in rust, you can force the resource out of scope via "drop" any time, which is what the fix does.
correct?
Re: (Score:2)
makes sense, thanks!
Re: (Score:2)
Re: Nope (Score:2)
The programmer made a mistake. Happens in C, happens in Rust. Unlikely that the programmer felt that everything in Rust is safe, especially after typing "unsafe" into their code.
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)
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)
Re: (Score:2)
Where did you find the idiot who told you that? Not even the most rabid Rust enthusiasts I have talked to would say something so dumb.
Re: (Score:2)
Rust is NOT memory safe (Score:2, Insightful)
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, Insightful)
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:2)
Re: Rust is NOT memory safe (Score:2)
I have written a fair bit of Rust, and spent a fair bit of time on the Rust forums as a result. I found it highly supportive, as well as polite and kind.
I've always tried to be polite on all social media, even as it has collapsed into its current state. But I still learned something from the Rust forums about this.
I am always surprised that people speak so negatively of the community.
Re: (Score:2)
Re:Rust is NOT memory safe (Score:5, 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)
Re: (Score:2)
people do claim Rust prevents any possibility of an error, or memory corruption.
You can find idiots spouting all kinds of nonsense; don't let them influence your thinking.
Re: (Score:2)
Re: (Score:2)
Except that no one claims seat belts prevents accidents
Who said accidents? Are you being intentionally dense? Seatbelts do the thing are claimed to do when they are used correctly. Rust does the thing it claims to do when it's used correctly.
Did you wake up on the stupid side of the bed this morning? ... And yesterday morning? Are you drunk every time you post on Slashdot?
Re: (Score:2)
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.
Which boils down to the paraphrased statement: “Seat belts prevent accidents.”, which get the appropriate answer of “Except that no one claims seat belts prevents accidents” because I've never heard anyone say that, or claim that, or have heard that third party.
I can show you people stating this about Rust, Lunduke covers Rust, fairly, openly and without bias. His coverage is open, so it's easy to find, and I don't really need more evidence than that, being the polarized reactions
Re: (Score:2)
Remember motorized seatbelts from the late 90's? They were more dangerous than regular seatbets as they would constantly whack me in the face and pinch my forehead.
Implementation matters.
Re: (Score:2)
They were more dangerous than regular seatbets
Citation required. Your feelings about motorised seatbelts or rust is irrelevant. Show us statistics. Here's a statistic for you: Number of unsafe rust actions able to be performed without declaring code unsafe: 0%
Sounds like a pretty good outcome. Maybe people who don't drive without seatbelts shouldn't be programmers because they make poor life choices?
Re: (Score:2)
Nothing is over. Except perhaps your credibility. Rust has never claimed what you think it does. It has a very clear definition of what it means by "memory safe" and a very clear definition of safe and unsafe code (see "unsafe" keyword).
Re: (Score:2)
Re: (Score:2)
Re: (Score:2)
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:5, Interesting)
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:
People acting like this is some kind of dunk on Rust are, quite frankly, embarrassing. Someone screwed up in the section flagged for "screwups are possible here". And then they fixed it.
Re: Big Yawn Here (Score:2)
Re:Big Yawn Here (Score:5, Funny)
C has had the "unsafe" declarator since its inception. It's very easy to see: if the file name ends in ".c", you know you're looking at potentially unsafe code and should be careful.
Re: Big Yawn Here (Score:2)
The type checker rather than the compiler per se. But, yes, the amount of reasoning the compiler can do is limited. It doesn't reason about the whole program, so might think that something could break while in practice other parts of the code prevent this.
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:3)
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, Funny)
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.
I like Rust... (Score:4, Insightful)
In this case, the language did exactly as designed, because sometimes you really prefer speed or simplicity of the code more than safety. With this particular line of code, perhaps the function that was called can be made safe. And, for the kernel, I think this implies unsafe sections should be scrutinized more closely, even if they're a single line.
The real problem I see is the assumption that Rust code will be bug free. A train doesn't require constant steering, but a conductor can run it off the tracks or ram it into another train. Rust is similar in how it drastically limits the degrees of freedom, but it doesn't stop a dedicated developer from writing bugs.
I'm not a programmer, but (Score:2)
/*unsafe*/ (Score:2)
What was the point? (Score:2)
Unlearned lessons. (Score:3)
The race occurred in a section of code not labelled unsafe. It was allowed to occur because the principles the borrow checker relies on were violated in a section that was.
This was not because C code had not addressed this challenge; someone thought, with a comment at the unsafe section, they would have safeguards and could take shortcuts. They released the lock guarding access to the mutable reference they held. This would not have occurred if that lock was correctly modelled to hold its contents, as std::sync::Mutex is intended to.
The developer who built the translation layer didn't apply the structural lessons in the standard library.
The claim this is "only a crash" is also wild speculation; memory corruption of this class may have wildly unpredictable effects, including replacing credentials or extracting information. It's detectable when it crashes.
Most notably, the bugfix addressed the final race. It did not address either of these structural weaknesses in the type modelling; meaning while this bug was fixed, the conditions that let it happen by accident were not. This has been the case in each of these publicised rust rewrite bugs I've seen.