The State of the Kernel Rust Experiment
Key topics
The Linux kernel's experiment with Rust is sparking heated debates about the language's potential to improve security. A recent CVE in Rust code has commenters divided, with some seeing it as a demonstration of Rust's strengths, while others argue it shows the language is not immune to security issues. The discussion reveals that even a data race resulting in memory corruption can be a contentious issue, with some downplaying its severity. As the Rust experiment moves forward, the debate is shifting from promises of security to nuanced discussions about the reality of vulnerabilities in Rust code.
Snapshot generated from the HN discussion
Discussion Activity
Very active discussionFirst comment
6d
Peak period
120
Day 7
Avg / period
26.8
Based on 134 loaded comments
Key moments
- 01Story posted
Dec 13, 2025 at 2:14 AM EST
21 days ago
Step 01 - 02First comment
Dec 19, 2025 at 12:38 AM EST
6d after posting
Step 02 - 03Peak activity
120 comments in Day 7
Hottest window of the conversation
Step 03 - 04Latest activity
Dec 22, 2025 at 11:42 AM EST
11 days ago
Step 04
Generating AI Summary...
Analyzing up to 500 comments to identify key contributors and discussion patterns
Want the full context?
Jump to the original sources
Read the primary article or dive into the live Hacker News thread when you're ready.
> 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
https://security.googleblog.com/2025/11/rust-in-android-move...
But don't take my word for it, you can hear about the benefits of Rust directly from GKH:
www.youtube.com/watch?v=HX0GH-YJbGw
There really isn't a good faith argument here. You can make mistakes in Rust? No one denies that. There is more C code so of course there are more mistakes in C code than in Rust? Complete red herring.
Why don't they use qmail as an example?
But you know that the mob voting will back you up.
Perhaps because qmail is an anomaly, not Android? To remain relatively bug-free, a sizeable C project seems to require a small team and iron discipline. Unix MTAs are actually pretty good examples. With qmail, for a long time, it was just DJB. Postfix has also fared well, and (AFAIK) has a very small team. Both have been architected to religiously check error conditions and avoid the standard library for structure manipulation.
Android is probably more representative of large C (or C++) projects one may encounter in the wild.
And it still wasn't enough. qmail has seen RCEs [0, 1] because DJB didn't consider integer and buffer overflows in-scope for the application.
[0] https://www.guninski.com/where_do_you_want_billg_to_go_today...
[1] https://lwn.net/Articles/820969/
And no, I do not care or even believe what Google says. There are so many influencing factors.
Essentially Weak Sapir–Whorf but for programming languages rather than natural languages. Which is such a common idea that it's the subject of a Turing Award speech. Because the code you read and write in Rust usually has these desirable safety properties, that's how you tend to end up thinking about the problems expressed in that code. You could think this way in C, or C++ but the provided tooling and standard libraries don't support that way of using them so well.
Rust is also often not the right tool. I looked at it fairly deeply some years ago for my team to transition away from Python/C hybrids, but settled on a fully garbage-collected language in the end. That was definitely the right choice for us.
[1] e.g. https://en.wikipedia.org/wiki/The_Power_of_10:_Rules_for_Dev...
The (in recent years) rapid adoption of Rust in industry clearly shows that this is not the case.
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.
An attempt:
Language-UB (L-UB): UB according to the guarantees of the language.
Project-compiler-UB (PC-UB): The project picks compilers and compiler settings to create a stronger set of guarantees, that turns some language-UB into not being UB. Examples include turning off the strict aliasing requirement in the used compilers, or a compiler by default defining some language-UB as being defined behavior.
I do not know if such terms might catch on, though. Do they seem reasonable to you?
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.
Its possible that you might be right about whatever point you're trying to make. But if you are, I can't tell that from your comments. I can't even find a clear claim in your comments, let alone any substantive argument in support of that claim.
I'm unmoved and unimpressed.
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.
Whether it is "significantly easier" to manage these types of problems and at what cost remains to be seen.
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.
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.
It is intended that Safe Rust be the main competitor to C. You are not meant to write your whole program in unsafe Rust using raw pointers - that would indicate a significant failure of Rust’s expressive power.
Its true that many Rust programs involve some element of unsafe Rust, but that unsafety is meant to be contained and abstracted, not pervasive throughout the program. That’s a significant difference from how C’s unsafety works.
The fix was outside of any Rust unsafe blocks. Which confused a lot of Rust developers on Reddit and elsewhere. Since fans of Rust have often repeated that only unsafe blocks have to be checked. Despite the Rustonomicon clearly spelling out that much more than the unsafe blocks might need to be checked in order to avoid UB.
Does anyone involved in any of this work believe that a CVE in an unsafe block could not happen?
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 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 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.
Safe rust isn't slow like Python, Go or Fil-C. It gets compiled to normal native code just like C and C++. It generally runs just as fast as C. At least, almost all the time. Arrays have runtime bounds checks. And ... thats about it.
> 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.
Nah. Most rust is safe rust. Even in the kernel, not much code actually interacts directly with raw hardware. The argument in favour of moving to rust isn't that it will remove 100% of memory safety bugs. Just that it'll hopefully remove most of them.
That's not true in practice: Unsafe code is clearly delineated and can be 100% correctly identified. In C, usage of dangerous features can occur at any point and is much harder to clearly separate.
Then yes, you can use dangerous features in C at any time, but obviously you can also use "unsafe" at any time. The only difference is that "unsafe" is clearer to recognize. But how much this is worth is unclear. First, if you do not invalidly reduce the discussion to only memory safety, you need to review all other code anyway! But even then, it is also not true that only the code marked with "unsafe" is relevant. This is major myth. The "unsafe" code can cause UB outside "unsafe" and logic bugs outside "unsafe" can cause bugs unsafe. This does not perfectly decouple if you Rust repeat this nonsense over and over again.
Don't get me wrong, I think the unsafe keyword is good idea. But the magical powers Rust fans attribute to it and the "SAFETY" comment they put next to it tells me they are a bit delusional.
This is the wrong understanding of Rust's unsafety encapsulation. For example, no logic bug outside of `unsafe` can cause undefined behavior of Rust std's `Vec` abstraction, which is using underlying unsafe to build.
The point that "because unsafe is used so the entire Rust program is also unsafe" is a real major myth. It's as absurd as saying "because Java runtime using unsafe underlying to build so Java is also unsafe".
The point coming back to abstraction and responsibility, in Rust, you can build abstraction that is sound and guarantee memory safety from there. There can be soundness bug inside your abstraction, but it will be a massively smaller surface for auditing and expert required to write such abstraction. Also, when soundness bug appears, the responsibility is solely on the abstraction writer, not the user.
Whereas in C, without those safe abstraction, the surface of doing thing right to avoid memory safety issue is your entire codebase, and responsibility of "holding the knife correctly" is on the user.
Why was the fix to this unsafe memory safety bug [0] only changes to code outside of unsafe Rust blocks?[1][2]
Why does the Rustonomicon[3] say the following?
> This code is 100% Safe Rust but it is also completely unsound. Changing the capacity violates the invariants of Vec (that cap reflects the allocated space in the Vec). This is not something the rest of Vec can guard against. It has to trust the capacity field because there's no way to verify it.
> Because it relies on invariants of a struct field, this unsafe code does more than pollute a whole function: it pollutes a whole module. Generally, the only bullet-proof way to limit the scope of unsafe code is at the module boundary with privacy.
[3] https://doc.rust-lang.org/nomicon/working-with-unsafe.html
[0] https://social.kernel.org/notice/B1JLrtkxEBazCPQHDM
[1] https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux...
[2] https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux...
Using rust's definition of unsafe which is roughly "can cause undefined behaviour" then it seems to me isolating use of these features isn't possible. What is C without:
* Dereferencing pointers * Array access * Incrementing signed integers
You can do all of the above without invoking UB, but you can't separate the features in C that can cause UB from the ones that can't.
For Rust safety (meaning no UB) most definitely is a property of the language. If a module does not contain unsafe and the modules it uses that do contain unsafe are implemented soundly then there is no UB.
In C UB is a part of the language.
Also "If .. are implemented soundly" sounds harmless but simply means there is no safety guarantee (in contrast to Fil-C or formally verified C, for example). It relies on best-effort manual review.
In C UB is part of the ISO language specification, but not necessarily part of a specific implementation of ISO C. If you argue that the ISO spec matters so much, I like to point out that Rust does not even have one, so from this perspective it is completely UB.
Don't those also depend on implementations being sound? Fil-C has its own unsafe implementation, formal verification tools have their trusted kernels, it's turtles all the way down.
What language do you think Graydon Hoare was spending most of this time writing while he started working of Rust as a side project? Hint: it sure wasn’t Java. Rust is not the product of some developer who has only used 2 scripting languages and had to read the definition of stack-smashing off of Wikipedia showing those C developers how to live in the future. It’s not old enough for many of the developers working on it to have only ever used Rust. It’s mostly C and C++ developers trying to build a new option for solving their same problems.
I've observed that a lot of the folks I used to meet at ruby conferences have moved to Rust. No idea what led to this, but maybe it's just folks that were generally curious about new programming languages that moved to ruby when it became better known and that the same interest led to adopting Rust.
But I don’t think that applies to the people actually driving the language forward, just those talking a big game on HN/Reddit.
I looked at firefox code a decade ago, it was a complete complex nightmare mix of different languages. I can see that this motivated starting something new, but it was not a clean C code base (and not even C).
But I also do not agree that memory safety is of much higher importance than other issues. Memory safety is highly critical if you have a monopolistic walled garden spyware ecosystem - such as Android. Not that I do not want memory safety, but the people I know who got hacked, did not get hacked because of memory safety issue, but because of weak passwords or unpatched software. And at least the later problems gets harder with Rust...
The claim has never, ever, been that Rust is bug free. The objective was to help reduce bugs, which is an outcome I've seen first hand in projects I work on. You still seem to speak in aggro terms, so it still feels like an emotional response to Rust.
The learning seems to be the only legitimate issue that people have. But they avoid mentioning it because it sounds intellectually lazy.
"You don't need to learn it or use it, we just want to do our own separate things with it over here"
.. some time later ..
"Oh yeah it's working good for us, we think it'd be useful to use it in these additional places, think about the benefits!"
.. some time later ..
"Now it's going to be core and required, either deal with it or get out"
They know they could never jump straight to the last step without revolt, so they shove their foot in the door with fake promises and smiles and then slowly over time force the door all the way open until they eventually get what they wanted from the beginning.
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
There's dozens of rust osdev projects. Its an open question if any become relevant like linux.
That remains to be seen. With a recent undefined behavior CVE, despite how little Rust there is, it would be prudent to wait before making such claims.
https://news.ycombinator.com/item?id=46309536
And yes, it is UB, in contrast to what Greg claims.
This talking point needs to stop. Rust could be a better language but that would be because it causes fewer bugs, not because the bugs are labeled "unsafe"
Your account is 1 day old.
I’m in a real dilemma here about whose word to take on the seriousness of this CVE.
> 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.
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.
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.
Wanting big fixes (including security fixes, because old machines can still be networked) and feature improvements, just like anyone else?
> I presume that outside of devices and drivers, there's little to no new developments in those architectures.
There's also core/shared features. I could very easily imagine somebody wanting eg. ebpf features to get more performance out of ancient hardware.
> 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?
Because backporting bits and pieces is both hard and especially hard to do reliably without creating more problems.
The long-term solution is for either of those to mature to the point where there is rust support everywhere that gcc supports.
tomshardware.com/software/linux/linux-dev-swatted-live-during-a-development-video-stream
Murderous, wretched Rust proponents will censor, downplay and distract from this.
I can see why mainly big corporations like Microsoft are pushing this onto community projects: Sabotage. It's highly opinionated and divides/disrupts the community and thus minimizes non-corporate community influence. The net benefits are negative by a huge amount on all fronts.
If you really want to help the world to get "safer" you would invest in better static analysis tools and proper annotation of existing C-Code. But it obviously was never about that.
While I could sort of see some situation like you describe with a secret agenda from big tech, I think that probably requires significantly more cunning & organisation than they actually have around this stuff. It's not like Microsoft invented Rust - in fact it came from a relatively small corp in the first place.
The Halloween documents show that Microsoft is playing these games for a long time now. Who knows in which way they have advanced their psyops. Just because we can't read their E-mails anymore doesn't mean they stopped doing it.
Compared to C where it has the opinion of no fixed data types making you deal with it.
>Systemd was equally opinionated and also caused huge division. Who is paying the bills of Poettering these days: Microsoft.
Systemd was only opinionated in how it should break posix, because it's meant to be Linux only.
And you're then saying that there is credible evidence that Poettering was a Microsoft mole almost 15 years ago with instructions to create systemd to "disrupt" the Linux ecosystem?
Boy did Microsoft fail there, more distros than ever adopted it and it's these days almost entirely pain free.
>The Halloween documents show that Microsoft is playing these games for a long time now. Who knows in which way they have advanced their psyops. Just because we can't read their E-mails anymore doesn't mean they stopped doing it.
If you have actually read the docs you would know that their strategy is not to divide and conquer as they say FUD does not work, but to instead compete with OSS.
And not individuals who work at Microsoft does not count.
How in the world does this not count? People act in the interest of those who pay the bills.
Guilty by association?
So do you have evidence of Microsoft the company doing this or not?
I found C way more approachable and rust filled to the brim with more rabbit holes and "logical-in-their-own-world/reality" way.. but again, I believe that's due to my own inexperience. Truthfully, in 10 years when rust fervor has died down and it has become more normal, I could see people vomitting at the thought that rust was pushed into the kernel, and there to be a strong push for not removing it but rather simplifying the code somehow? I'll definitely be taking another crack at rust again in the next couple of years though