After five years real shipping Android devices, growing subsystem adoption and active compiler support it’s hard to call this anything but a success. Rust in the kernel isn’t about replacing C overnight it’s about making new code safer and attracting new contributors and by those measures it’s clearly working.
There's this bit from the article which might provide a hint:
> Drivers in Rust, [Greg KH] said, are indeed proving to be far safer than those written in C.
And since CVEs haven't been getting assigned to Rust code until recently, I think he's more well-positioned to opine on the safety of Rust code vs. C code in Linux than those who are only indexing off the singular Rust CVE so far.
There is relatively little Rust in the kernel, but there are even less Rust CVEs. In this cycle alone there were 160 CVEs, one in Rust. The first one! The amount of rust is way less than 1/160 and even that statistic is off, because one should count all CVEs.
That is debatable, and I think untrue. It sometimes takes years to find CVEs in C code, and I don’t know of an argument why that would be different for Rust.
The fairest comparison, I think, would be with other new code of similar complexity in the kernel, and track #of CVEs per equivalent functionality (per line of code might be sufficient, but if one language is verbose than the other, you should correct for that)
>Bergmann agreed with declaring the experiment over, worrying only that Rust still "doesn't work on architectures that nobody uses".
I love you Arnd.
More seriously, this will become an issue when someone starts the process of integrating Rust code into a core subsystem. I wonder whether this will lead to the kernel dropping support for some architectures, or to Rust doing the necessary work. Probably a bit of both.
There are two separate ongoing projects to make a rust compiler that uses GCC as a backend (one on the gcc side adding a c++ frontend that directly reads rust, one on the rustc side to make rustc emit an intermediate format that gcc can ingest).
The long-term solution is for either of those to mature to the point where there is rust support everywhere that gcc supports.
I suspect more the latter than anything. It could be that by the time Rust gets used in the kernel core, one or both of the GCC implementations would be functional enough to compile the kernel.
I'm curious though, if someone has an ancient/niche architecture, what's the benefit of wanting newer kernels to the point where it'd be a concern for development?
I presume that outside of devices and drivers, there's little to no new developments in those architectures. In which case, why don't the users/maintainers of those archs use a pre-6.1 kernel (IIRC when Rust was introduced) and backport what they need?
No one is doing any kind of serious computing on 30 year old CPUs. But the point of the hobby isn’t turning on the computer and doing nothing with it. The hobby is putting together all the pieces you need to turn it on, turning it on and then doing nothing with it.
There’s an asymmetry in what the retro computing enthusiasts are asking for and the amount of effort they’re willing to put in. This niche hobby benefits from the free labour of open source maintaining support for their old architectures. If the maintainers propose dropping support because of the cost of maintenance the hobbyists rarely step up. Instead they make it seem like the maintainers are the bad guys doing a reprehensible thing.
You propose they get their hands dirty and cherry pick changes from newer kernels. But they don’t want to put in effort like that. And they might just feel happier that they’re using the “real” latest kernel.
Once again, congrats to the R4L team! It's a big milestone and I'm looking forwards to future developments!.
There was a lot of interesting discussion on the previous post [0], but one thing I didn't see was much discussion about this bit:
> The DRM (graphics) subsystem has been an early adopter of the Rust language. It was still perhaps surprising, though, when Airlie (the DRM maintainer) said that the subsystem is only "about a year away" from disallowing new drivers written in C and requiring the use of Rust.
I was a bit surprised when I first read this. Is this meant to be read in a way that is more just a description of the state of Rust bindings (e.g., the DRM subsystem is about a year away from being able to require the use of Rust, but isn't actually planning on doing so), or it is describing actual plans (e.g., the DRM subsystem is about a year away from actually requiring the use of Rust)? I was originally more inclined to go for the former interpretation, but this other bit:
> With regard to adding core-kernel dependencies on Rust code, Airlie said that it shouldn't happen for another year or two.
Makes me think that perhaps the devs are actually considering the latter. Is anyone more in-the-know able to comment on this?
I'm not more "in the know" but it makes sense that new drivers could require it. New drivers, after all, are pretty much always written for newer platforms that Rust has support for. The main issue with enabling Rust (let alone requiring it) is that Linux still supports platforms which Rust does not.
I don't know. My line of thinking is that if the Linux devs are comfortable with using Rust in core Linux then they might also be comfortable requiring Rust for new drivers as well. No idea if that makes sense, though.
> To me the more salient questions are how long before (a) we get Rust in a core subsystem (thus making Rust truly _required_ instead of "optional unless you have hardware foo"), and (b) requiring Rust for _all_ new code.
Previously, the position was that C developers would not be forced to learn Rust.
And a few days ago a security vulnerability was found in the Rust Linux kernel code.
Where did anyone promise that the Rust bits will never have security issues? That CVE was a fantastic demonstration of just how much better the situation is in Rust code and I don't think there's a realistic argument that the experiment has been anything other than successful.
This is certainly not true. But also arguments about "common" are completely misleading as long as there is many orders of magnitude more C code than Rust code.
That is is undefined behavior does not mean it is exploitable. But I also have not seen an argument why a data race should not be exploitable in this context.
I am very wary of going that route. If there is undefined behavior, the compiler is in principle allowed to do anything and everything, unless it promises something beyond what the language promises.
One could then argue that a specific version of a specific compiler with specific settings in a specific case, after investigation of the generated assembly or inspection of what guarantees the compiler provides beyond the language, is not exploitable. But other settings of the compiler and other versions of the compiler and other compilers may have different guarantees and generation of assembly.
The Linux kernel uses, as I understand it, a flag for GCC for C code that disables strict aliasing. That basically means that strict aliasing is no longer undefined behavior, as long as that flag is used. Basically a dialect of C.
It is very common for C implementation to define undefined behavior and also common for C programs to rely on this. For this reason, I think it is very misleading to say that undefined behavior is automatically exploitable or even a bug.
> 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)
> 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.
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").
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
There are lots of vulnerabilities in the C code, too. Should we remove C or do we accept that fact that no language is perfect since they are used by humans and continue to make improvements and use tools that help us along as time goes forward?
The cherry picking for this one Rust vulnerability to the ~150 C vulnerabilities is such a weird take that I can't help but think people have some weird hatred of Rust.
Your post is curious, for the post I quoted basically argued for just that eventuality for all new code. Even as the new language introduces undefined behavior vulnerabilities.
The promises as stated previously, and the goal as stated by that lwn.net post now, are starkly different. And the poster did not even wait until the new language has proven its worth. And then a UB CVE comes by in the code in the new language.
> So when you change the C interfaces, the Rust people will have to deal with the fallout, and will have to fix the Rust bindings. That's kind of the promise here: there's that "wall of protection" around C developers that don't want to deal with Rust issues in the promise that they don't have to deal with Rust.
That both you and that lwn.net poster writes these things, is extraordinarily weird and strange.
I do not think it is weird. Every C bug was taken as clear evidence that we need to abandon C and switch to Rust. So the fact that there are also such bugs in Rust is - while obvious - also important to highlight. So it is not weird hatred against Rust, but hatred against bullshit. And considering that most of the code is C, your 150 C vulnerabilities is a meaningless number, so you still continue with this nonsense.
> Every C bug was taken as clear evidence that we need to abandon C and switch to Rust.
I think more charitably it's every "simple" C bug that tends to provoke that reaction. Buffer overflows, use-after-frees, things for which mechanically-enforceable solutions have existed and been widespread for a while. I think more exotic bugs tend to produce more interesting discussions since the techniques for avoiding those bugs tend to be similarly exotic.
> So the fact that there are also such bugs in Rust
Similarly, I think you need to be careful about what exactly "such bugs" encompasses. This bug wasn't one of the above "simple" bugs IMHO, so I would guess an equivalent bug in C code would at least avoid the worst of the more strident calls you so dislike. Hard to say for sure, though, given our unfortunate lack of a time machine.
Safe Rust eliminates some of the more common memory bugs in C. The bug under discussion was written in unsafe Rust—but even that doesn't obviate the huge advantages Rust has over C. Even unsafe Rust, for instance, has far fewer UB gotchas than C. And with Rust, you can isolate the tricky bits in 'unsafe' blocks and write higher-level logic in safe Rust, giving your code an extra layer of protection. C is 100% unsafe—"unsafe at any speed" as I like to say.
IMHO, "C is 100% unsafe" is a misleading way to look at it and the kind of exaggeration which I criticize. Also in C only specific language features are unsafe and not all code, and you can screen for these features and also isolate critical code in helper functions. Saying these features could appear everywhere is no difference from "unsafe" possibly appear everywhere in Rust. I agree that "unsafe" is easier to find as a keyword, but I do not think this is a fundamental advantage, especially in projects where you have a lot of such "unsafe" blocks.
The point is that when you start using rust in the real world to get real work done a lot of the promises that were made about safety have to be dropped because you need to boot your computer before the heat death of the universe. The result will be that we end up with something about as safe as C is currently - because CPUs are fundamentally unsafe and we need them to work somehow.
Rust is from the universe in which micro kernels weren't a dead end and we could avoid all the drivers being written in C.
If you build a house out of inflammable bricks instead of magnesium ones you can at least rule out magnesium fires.
Now the question is: If we live in a world where magnesium fires are common, can we afford to not at least try building with the inflammable bricks?
I know this topic stokes emotions, but if you haven't tried Rust as someone with C/C++ experience, give it a go. You will come out wiser on the other side, even if you never use the language for anything.
Offtopic but this title makes me want to create an alternate-universe version of the HN front page where every title is shrill/spectacular/hysterical/urgent/clickbaity. Such as:
The Absolute State of the Kernel Rust Experiment Right Now
And every comment has its confidence/aggressiveness taken up to 11 (tho still within site rules).
> Drivers in Rust, [Greg KH] said, are indeed proving to be far safer than those written in C.
And since CVEs haven't been getting assigned to Rust code until recently, I think he's more well-positioned to opine on the safety of Rust code vs. C code in Linux than those who are only indexing off the singular Rust CVE so far.
That is debatable, and I think untrue. It sometimes takes years to find CVEs in C code, and I don’t know of an argument why that would be different for Rust.
The fairest comparison, I think, would be with other new code of similar complexity in the kernel, and track #of CVEs per equivalent functionality (per line of code might be sufficient, but if one language is verbose than the other, you should correct for that)
Your account is 1 day old.
I’m in a real dilemma here about whose word to take on the seriousness of this CVE.
As opposed to an implicitly unsafe what 1 million lines of C
I love you Arnd. More seriously, this will become an issue when someone starts the process of integrating Rust code into a core subsystem. I wonder whether this will lead to the kernel dropping support for some architectures, or to Rust doing the necessary work. Probably a bit of both.
The long-term solution is for either of those to mature to the point where there is rust support everywhere that gcc supports.
I'm curious though, if someone has an ancient/niche architecture, what's the benefit of wanting newer kernels to the point where it'd be a concern for development?
I presume that outside of devices and drivers, there's little to no new developments in those architectures. In which case, why don't the users/maintainers of those archs use a pre-6.1 kernel (IIRC when Rust was introduced) and backport what they need?
There’s an asymmetry in what the retro computing enthusiasts are asking for and the amount of effort they’re willing to put in. This niche hobby benefits from the free labour of open source maintaining support for their old architectures. If the maintainers propose dropping support because of the cost of maintenance the hobbyists rarely step up. Instead they make it seem like the maintainers are the bad guys doing a reprehensible thing.
You propose they get their hands dirty and cherry pick changes from newer kernels. But they don’t want to put in effort like that. And they might just feel happier that they’re using the “real” latest kernel.
There was a lot of interesting discussion on the previous post [0], but one thing I didn't see was much discussion about this bit:
> The DRM (graphics) subsystem has been an early adopter of the Rust language. It was still perhaps surprising, though, when Airlie (the DRM maintainer) said that the subsystem is only "about a year away" from disallowing new drivers written in C and requiring the use of Rust.
I was a bit surprised when I first read this. Is this meant to be read in a way that is more just a description of the state of Rust bindings (e.g., the DRM subsystem is about a year away from being able to require the use of Rust, but isn't actually planning on doing so), or it is describing actual plans (e.g., the DRM subsystem is about a year away from actually requiring the use of Rust)? I was originally more inclined to go for the former interpretation, but this other bit:
> With regard to adding core-kernel dependencies on Rust code, Airlie said that it shouldn't happen for another year or two.
Makes me think that perhaps the devs are actually considering the latter. Is anyone more in-the-know able to comment on this?
[0]: https://news.ycombinator.com/item?id=46213585
> To me the more salient questions are how long before (a) we get Rust in a core subsystem (thus making Rust truly _required_ instead of "optional unless you have hardware foo"), and (b) requiring Rust for _all_ new code.
Previously, the position was that C developers would not be forced to learn Rust.
And a few days ago a security vulnerability was found in the Rust Linux kernel code.
https://news.ycombinator.com/item?id=46309536
One could then argue that a specific version of a specific compiler with specific settings in a specific case, after investigation of the generated assembly or inspection of what guarantees the compiler provides beyond the language, is not exploitable. But other settings of the compiler and other versions of the compiler and other compilers may have different guarantees and generation of assembly.
The Linux kernel uses, as I understand it, a flag for GCC for C code that disables strict aliasing. That basically means that strict aliasing is no longer undefined behavior, as long as that flag is used. Basically a dialect of C.
Greg Kroah-Hartman has been a Linux kernel developer for 25 years, responsible for large parts of the kernel.
You’ve been a hacker news commenter for 1 day.
Could you pipe down with these wild claims that you know better than him?
Also, please don’t complain about downvotes. It’s tedious to read.
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)
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...
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.
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
I do not blame you, for you had the competence and honesty to ask instead of incompetently and dishonestly jumping to incorrect conclusions.
The learning seems to be the only legitimate issue that people have. But they avoid mentioning it because it sounds intellectually lazy.
The cherry picking for this one Rust vulnerability to the ~150 C vulnerabilities is such a weird take that I can't help but think people have some weird hatred of Rust.
Your post is curious, for the post I quoted basically argued for just that eventuality for all new code. Even as the new language introduces undefined behavior vulnerabilities.
The promises as stated previously, and the goal as stated by that lwn.net post now, are starkly different. And the poster did not even wait until the new language has proven its worth. And then a UB CVE comes by in the code in the new language.
What Linus wrote in the past:
https://www.phoronix.com/news/Torvalds-On-Rust-Maintainers
> So when you change the C interfaces, the Rust people will have to deal with the fallout, and will have to fix the Rust bindings. That's kind of the promise here: there's that "wall of protection" around C developers that don't want to deal with Rust issues in the promise that they don't have to deal with Rust.
That both you and that lwn.net poster writes these things, is extraordinarily weird and strange.
I think more charitably it's every "simple" C bug that tends to provoke that reaction. Buffer overflows, use-after-frees, things for which mechanically-enforceable solutions have existed and been widespread for a while. I think more exotic bugs tend to produce more interesting discussions since the techniques for avoiding those bugs tend to be similarly exotic.
> So the fact that there are also such bugs in Rust
Similarly, I think you need to be careful about what exactly "such bugs" encompasses. This bug wasn't one of the above "simple" bugs IMHO, so I would guess an equivalent bug in C code would at least avoid the worst of the more strident calls you so dislike. Hard to say for sure, though, given our unfortunate lack of a time machine.
The point is that when you start using rust in the real world to get real work done a lot of the promises that were made about safety have to be dropped because you need to boot your computer before the heat death of the universe. The result will be that we end up with something about as safe as C is currently - because CPUs are fundamentally unsafe and we need them to work somehow.
Rust is from the universe in which micro kernels weren't a dead end and we could avoid all the drivers being written in C.
Now the question is: If we live in a world where magnesium fires are common, can we afford to not at least try building with the inflammable bricks?
I know this topic stokes emotions, but if you haven't tried Rust as someone with C/C++ experience, give it a go. You will come out wiser on the other side, even if you never use the language for anything.
The Absolute State of the Kernel Rust Experiment Right Now
And every comment has its confidence/aggressiveness taken up to 11 (tho still within site rules).