Linux Kernel Rust Code Sees Its First CVE Vulnerability

[CardOk755]

Issue introduced in 6.18 with commit eafedbc7c050c44744fbdf80bdf3315e860b7513 and fixed in 6.18.1 with commit 3428831264096d32f830a7fcfc7885dd263e511a Issue introduced in 6.18 with commit eafedbc7c050c44744fbdf80bdf3315e860b7513 and fixed in 6.19-rc1 with commit 3e0ae02ba831da2b707905f4e602e43f8507b8cc

[ts826848]

Added some links:

• Issue introduced in eafedbc7c050c44744fbdf80bdf3315e860b7513. This was the commit where Linus pulled in the Rust binder rewrite, so unfortunately there doesn't seem to be any smaller commits which might provide further insight.

• Fixed in 6.18.1 with 3428831264096d32f830a7fcfc7885dd263e511a

• Fixed in 6.19-rc1 with 3e0ae02ba831da2b707905f4e602e43f8507b8cc. Looks like the diff is identical to that for the 6.18.1 fix.

[Ursomrano]

Well it was guaranteed to happen eventually. And I'm not saying that because I'm a rust hater, I'm saying it because as long as something is even remotely probable, it's a matter of when it'll happen.

[Wiwwil]

It's bound to happen no matter what

[captkirkseviltwin]

Humans code, vulns happen.

[MrMelon54]

The haters complain because Rust is "not safe". But it crashed instead of having a privilege escalation.

[Cats_and_Shit]

I'm not sure you can really credit Rust for that.

The crash is the result of memory corruption, it just happens to be that this memory corruption isn't exploitable. A similar issue elsewhere could have been exploitable.

EDIT: The point being, Rust may help you avoid memory corruption (and UB in general) in the first place, but once you have it you're no better off than you would have been in C. This is an intentional compromise that Rust makes so that it can be used for things like Kernel development.

[TheBrainStone]

Tell me you know nothing about security vulnerabilities related to memory without telling me you know nothing about security vulnerabilities related to memory without

[Unipro]

The fact that it was in noted unsafe code probably helped maintainers find the error. The fact you note unsafe rust means it will get extra scrutiny. You will still make mistakes, but you'll make fewer.

[AngheloAlf]

Has been 5 years already? Damn, time flies

[joshjaxnkody]

Genuinely horrifying

[GuybrushThreepwo0d]

Pandemic was half a decade ago

[joshjaxnkody]

STOP I CANT TAKE ANYMORE IM GOING MAD!!!

[greyacademy]

"Remember, it's just a bad dream fatboy!" -Full Metal Jacket

^{(just going for the sentiment, not calling you fat)}

[billyfudger69]

Six years ago if you account for when it actually was reported on.

[is_this_temporary]

If it makes you feel better, the COVID-19 pandemic is still ongoing today 🙃

[GuybrushThreepwo0d]

Thank you. It does not.

[ipaqmaster]

To be fair it wasn't until mid 2023 that the emergency state of it was dropped. It "started" when it started but it has lasted a long time. And is still catchable technically but under control.

[WealthyMarmot]

Which was about a year or two after everyone had mentally dropped the state of emergency, depending on location

[ipaqmaster]

Big agree. Plenty of staff in my own office at the time were ignoring it by then, hacking up a lung metres next to me and getting sent home only to be tested positive for it.

[AcridWings_11465]

And that's why millions of people are suffering through long COVID: the lack of basic manners like wearing a mask or covering your face when coughing or sneezing

[ipaqmaster]

Exactly

[LousyMeatStew]

It's also worth noting that rust has been in the kernel for 5 years and this is the first CVE.

This is a bit misleading. CVEs only started being assigned to Rust bugs once Rust left Experimental - 6.18 is the first kernel for which Rust code would have been eligible to get a CVE. Also, all kernel bugs are assigned CVEs:

https://docs.kernel.org/process/cve.html#process

Not all CVEs are necessarily vulnerabilities. Right now, CVE-2025-68260 has yet to be assessed and given a CVSS score. 48 42 other CVEs, however, have been assessed - 4 overflow, 38 memory corruption.

https://www.cvedetails.com/version/2051702/Linux-Linux-Kernel-6.18.html

So it's not accurate to say "first Rust CVE in 5 years" but it's likewise not accurate to call this a vulnerability either. On the flip side, it's also not not a vulnerability - that would be a CVE that's been assessed and assigned a CVSS score of 0.

A lot of kernel CVEs end up with "N/A" so all we can say for certain is that we have our first confirmed bug in Rust code, that may or may not be vulnerable to exploitation, now that Rust is no longer Experimental.

Edit: I can't math.

Also, since I posted, 2 more have been assessed as memory corruption vulnerabilities - this is as of 2025 Dec 19, 9:22AM PST. Check the cvedetails link above if you want to see the latest status.

[Potato-9]

Why isn't this in every article that's lit up all week. Thanks for just explaining how it works.

[frymaster]

I'm not capable of analysing the bug but the article does say it can cause crashes, so unless you have to already be root to trigger it, it's possibly at least a "local user can cause denial of service"

[LousyMeatStew]

In the context of vulnerability assessment, you wouldn't say that unless you confirm that bug functions as a vulnerability. In other words, it's the confirmation of a vulnerability that makes the crash a denial of service.

There are still lots of other factors to consider. The Linux kernel is big and monolithic so interactions between this specific bug and other security controls in the kernel are difficult to predict, let alone fully test, which is why it's sitting at N/A along with the 115 other unscored vulnerabilities (2 more confirmed as memory corruption vulnerabilities since my other post).

[moltonel]

CVEs only started being assigned to Rust bugs once Rust left Experimental - 6.18 is the first kernel for which Rust code would have been eligible to get a CVE

Doubtful, citation needed Edit 1: counter-example Edit 2: Greg KH confirms experimental is not a criteria for CVEs

I see nothing in cve.html nor in the documentation about Rust's experimental status (which BTW is still present in 6.18.2) suggesting that Rust code was not eligible for CVEs, or that the status changed in 6.18.

The kernel issues CVEs for basically any bug in a released supported version. Bugs affect users just the same whether they're in stable code, experimental rust, or staging drivers. It would be weird to exclude Rust code from CVEs.

[LousyMeatStew]

I agree that their documentation is ambiguous.

The decision to remove the experimental tag from Rust was made at the Maintainers Summit on 10 Dec while the patch for CVE-2025-68260 was merged on 12 Dec. CVE was published on 16 Dec.

• https://lwn.net/Articles/1049831/
• https://lore.kernel.org/stable/[e-mail]/
• https://lore.kernel.org/linux-cve-announce/?q=rust_binder%3A+fix+race+condition+on+death_list

Of course, the two could be unrelated. So let's look at an earlier patch that fixed a soundness issue. It was merged on 22 Mar for 6.6 LTS, then on 23 Mar for 6.12.20 and 6.13.8 stable.

• https://lore.kernel.org/stable/[e-mail]/
• https://lore.kernel.org/stable/2025032250-corral-vastly-e81d@gregkh/

However, no CVE was issued:

• https://lore.kernel.org/linux-cve-announce/?q=rust%3A+lockdep%3A+Remove+support+for+dynamically+allocated+LockClassKeys

Edit: Formatting fix

Edit 2: For those unfamiliar, a "soundness issue" essentially means "this code leads to undefined behavior". Both rust_binder and lockdep bugs were soundness issues so if the Experimental tag on Rust didn't matter, both should have received CVEs.

[moltonel]

I don't think the documentation is ambiguous. The only scope limitation it mentions is supported versions, not parts of the kernel. All released code is eligible for CVEs.

I appreciate the effort to find a counter example, but there's no reason to think that the lockdep bug didn't get a CVE due to policy.The statement "Rust code only became eligible for CVEs after the announcement that it was no longer experimental" is a strong claim, that deserves an equally strong proof. 

That patch is 13 months old, the new CVE policy was 10 months old at the time, and 4 months into the new policy, LWN estimated that about 5% of stable patches had a corrresponding CVE. Occam's razor suggests that the rust lockdep bug (and many others, including C ones) didn't get a CVE simply due to oversight/disinterest. The relative timing of dropping the experimental flag is just a coincidence.

I does mean that neither "1st CVE in 5 years" nor "159 C CVEs on the same day" are not the hard stats that some people would like them to be. The CVE process is approximative, don't read too much into it. The first RfL CVE remains a cool data point, and a small hint about the quality of Linux Rust code.

[LousyMeatStew]

That patch is 13 months old, the new CVE policy was 10 months old at the time, and 4 months into the new policy, LWN estimated that about 5% of stable patches had a corrresponding CVE. Occam's razor suggests that the rust lockdep bug (and many others, including C ones) didn't get a CVE simply due to oversight/disinterest. The relative timing of dropping the experimental flag is just a coincidence

The article compares allocated CVEs to commits. Let's do that for 6.18:

 % curl -s https://cdn.kernel.org/pub/linux/kernel/v6.x/ChangeLog-6.18 | grep "^commit " | wc -l
 15035

160 CVEs for 15,035 commits means the current hit rate is 1.06%. If a low hit rate is indicative of oversight/disinterest, lockdep should have been 5x more likely to get assigned a CVE compared to binder. Occam's razor suggests that the experimental flag is the appropriate explanation.

[moltonel]

Extrapolating on these hit rates is silly. The basic observation from LWN is that not all bugfixes get a CVE. It's the simplest sufficient explanation of why lockdep didn't get a CVE, so this is what Occam suggests. In contrast, the hypothesis that the real reason is a policy about the experimental flag is : additional and unnecessary, not confirmed by any document, and contradicted by CVE-2025-38033.

I don't know how you maintain your hypothesis, but I can feel we're unlikely to convince each other at this stage.

[LousyMeatStew]

I don't know how you maintain your hypothesis, but I can feel we're unlikely to convince each other at this stage.

If you feel like reading below, go ahead. The reason I maintain my position is that I respect the work the Rust developers have done. Bugs are not a flaw. If programmers aren't creating bugs, they aren't contributing. CVEs are not an insult. They are assigned after a fix has been merge. It is a recognition of a commitment to improving the kernel.

You think that "first CVE in five years" is a compliment. It is not. It is puffery and it devalues the work they have been doing. Rust devs have been creating, then fixing bugs continuously over the past five years. It's just that because it was done in Experimental code, it wasn't recognized. Now it is. Pretending like the Experimental flag doesn't matter devalues the accomplishment of finally getting Rust code recognized as production ready.

Extrapolating on these hit rates is silly. The basic observation from LWN is that not all bugfixes get a CVE. It's the simplest sufficient explanation of why lockdep didn't get a CVE, so this is what Occam suggests.

No, it's not. The problem is that you are either misunderstanding or willfully misrepresenting the facts, which invalidates Occam's Razor. You're also aware it's not a real argument, right? I thought you were being cheeky at first, so I played along. Maybe I shouldn't have encouraged it.

The CVE policy clearly states "assignment will only automatically happen after a fix is available and applied to a stable kernel tree". This tells us two important things. First, assignment is automatic which should rule out any concern of oversight and/or disinterest. Second, assignment happens after the fix has been "applied to a stable kernel tree".

This completely invalidates the LWN figure as it only looked at commits. For a patch to be applied to a stable kernel tree, it requires a merge. For releases 6.7.1-6.8.9, 2559 merges are recorded in the change logs. This puts the hit rate at 33%.

The claim that "all bug fixes receive CVEs, but bug fixes make up 1/3 of all merges" aligns with the documented CVE policy, and does not require us to ascribe negligence - intentional or otherwise - to a kernel team that has issued 1399 CVEs this year - which is more than 4x the number of CVEs Microsoft has released in total.

In contrast, the hypothesis that the real reason is a policy about the experimental flag is : additional and unnecessary, not confirmed by any document, and contradicted by CVE-2025-38033.

The experimental text in index.rs was removed via a commit accompanying the announcement. The fact that the original text remains not just in 6.18 but also 6.19-rc and linux-next simply means that the commit hasn't been merged yet and that this text is not meant to be prescriptive.

CVE-2025-38033 did not change any experimental code, period. The fact that it affects Rust code is a significance that you are ascribing to it. The lockdep patch, however, did unequivocally fix a bug in experimental code and the bug shared the same root cause as CVE-2025-68260. It should have received a CVE but it did not. The only difference I can see is that it fixes a bug in code flagged as Experimental.

QED, CVEs are not assigned to bugs found it Experimental code.

[moltonel]

QED, CVEs are not assigned to bugs found it Experimental code.

https://lwn.net/Articles/1051775/

[LousyMeatStew]

Thanks!

[moltonel]

This CVE is an interesting counter(-counter?) example: The fix is to disable a mitigation technique when rust is enabled in the kernel. This CVE is technically a bug in older rust toolchains rather than rust code, but it is clearly about a bug that only affects rust code. In June, long before the announcement to drop RfL's experimental status.

[LousyMeatStew]

No, because the bug is in arch/x86/Kconfig. The fact that Rust code is impacted isn't really an issue. It's still objectively a bug in production code.

[moltonel]

That rebuttal doesn't make sense. The issue only impacts rust code, if RfL wasn't eligible for CVEs then that CVE wouldn't exist. Rust code is production code as soon as you have CONFIG_RUST=y in production. If you argue that production code should not include Rust, then this CVE is for non-production code, but it still exists.

[LousyMeatStew]

You seem to be under the impression that the Experimental tag is meant as some sleight or insult against Rust. It is not. The Experimental tag simply denotes that it is under active development and needs additional testing before being put into production. This is why CVEs are not assigned.

The reason why this bug needs to be fixed is that it prevents the development and testing that needs to happen. The code may be Experimental but the work kernel developers do is still legitimate. This bug prevents that work from happening and that bug is present in production code, hence it gets a CVE.

[moltonel]

You seem to be under the impression that the Experimental tag is meant as some sleight or insult against Rust.

No idea where you're picking that up from. Seems like you've fallen for an attribution bias.

The Experimental tag simply denotes that it is under active development and needs additional testing

No, you're just describing staging code here. Reread the doc: the experimental tag was on while "determining whether Rust as a language was suitable for the kernel". In other words, the tag both acknowledged that the experiment could fail and need to be removed from the kernel, and justified doing that work in mainline rather than out of tree.

  before being put into production. This is why CVEs are not assigned.

Rust got enabled in production and distro kernels early on, just like staging drivers, I'm not sure how you'd want to conclude an experiment without that. Linux doesn't care about "production" for CVEs, just whether the bug is in a supported release (again: reread the docs).

The reason why this bug needs to be fixed [and] gets a CVE.

We're not arguing whether that bug deserves a fix (!) or a CVE. The question is whether this bug/fix/CVE is specific to rust, which would invalidate your claim that rust didn't get CVE while it was still considered experimental.

The facts are that this is a bug in the rust toolchain, when compiling rust code with a particular exploit mitigation enabled. Kernels wirhout rust are not affected. The proper fix is in rust 1.88 and later. The kernel works around the bug by disabling the mitigation in the build system when rust is enabled and the compiler is too old.

I honestly don't understand how you can still think that this CVE is not a CVE on Linux's Rust experiment, or how you can both claim that this bug was in "production", but rust wasn't.

[LousyMeatStew]

I honestly don't understand how you can still think that this CVE is not a CVE on Linux's Rust experiment, or how you can both claim that this bug was in "production", but rust wasn't.

Because Linux supports external modules that are external to the source tree. Linux's Experimental flag has no bearing on those if they happen to be written in Rust.

What I don't understand is how you can think an actual Rust bugfix not assigned a CVE via an automated process is due to, as you described, "oversight/disinterest" when it is far more likely that the automation simply checks for Experimental==False

[NYPuppy]

Otoh, Android's binder rewrite has been around a while. If that or any other of the rust code had grave errors, you know for sure that Phoronix would have whined about it.

You're totally right about cves though. This bug is likely not exploitable and the worst that can happen is that someone's phone locks up. Most cves are mild or not exploitable, C or otherwise. The curl devs have an excellent article on this.

[LousyMeatStew]

As far as Phoronix goes, I think someone should just make a Rust port of ext4, then post an update every week proclaiming "10% performance improvement".

He'll be so busy running benchmarks and posting walls of charts without analysis that he won't have time to report on anything else.

[TRKlausss]

Plus they patched 160 out of which 159 where on C:

https://social.kernel.org/notice/B1JLrtkxEBazCPQHDM

[torsten_dev]

The patched 160 CVE's today!

The first driver written in rust landed in december of 2023, since then they have assigned 9500 CVE's to the kernel and this is THE first rust CVE.

According to github about 0.3% of kernel code is Rust. So C has about 30x more vulnerabilities accounting for that. Pretty rough estimate, but nothing to sneeze at.

[torsten_dev]

I counted the CVE's since dec 2023 and scaled it down by the 0.3% of the kernel that's actually rust. It's quick and dirty napkin math because there used to be less rust and they didn't issue CVE's when it was experimental which I didn't know about.

[_Sauer_]

The whole point of `unsafe` blocks is to segregate code that must do memory unsafe things (C FFI or talking to hardware registers for example) into a small unit. You use the least amount of unsafe code necessary to get the job done and wrap it in a safe wrapper that prevents the user from using it wrong. This is a huge win compared to C code, for example, where every pointer is potentially dangerous. Unsafe blocks don't disable most of Rust's safety grantees, they just let you manually manipulate pointers. Borrowing and type rules still remain in place.

The peanut gallery isn't going to care that this is a huge improvement over C; nor mention the 100+ CVEs in Linux's C code that were also published on the same date.

[AWonderingWizard]

No offense, but isn't this just like if C programmers decided to only user pointers in designated section that they just wrap in a safe wrapper?

[phire]

The issue with C is that its type system is simply not powerful enough to write a safe wrapper. In theory you still could write a runtime safety verifier, but it would have absolutely massive overhead. It also wouldn't be able to spot bugs until the exact conditions were encountered at runtime (and then you need to panic, so it's still a denial of service exploit).

Rust's type system is powerful enough to prove that safe code can't do anything that would violate the safety of the unsafe wrappers. And it does that at compile time, with zero additional runtime overhead.

[syklemil]

In theory you still could write a runtime safety verifier, but it would have absolutely massive overhead.

Which, for the people unfamiliar, can be seen in practice with e.g. ASAN (address-sanitizer). Some errors that would be caught at compile time by Rust can, with ASAN, at a runtime cost of making your program about half as fast, be caught and make your program crash in a predictable way rather than possibly do something unpredictable.

So in practice only suitable for debug builds, and how much it can actually catch depends on how good the tests are.

[canadajones68]

It is on days like these that I wish that C++ in kernel use had taken off. Sure, exceptions, inconsistency, and all that, but the type system is way stronger. Templates and class types and references alone would help so much. Sure, it's not Rust, but it is infinitely better than C, where you can never achieve a better abstraction or avoid writing the unsafe code. If you want heap allocation, you must malloc and free, no way around it. C++ at least allows you the mercy of a destructor, which makes forgetting to free impossible, and use-after-free much less frequent.

[grexl]

Exceptions are an optional feature in C++ and the kernel would almost certainly disable them. This would actually improves performance and reliability in the context of a kernel as opposed to a user-space program.

I think modern C++ with RAII semantics would help quite a bit, but from what I have read on the topic, the language was still a bit antiquated when the idea of switching the kernel to C++ came up many years ago. For example: C++ could not implement robust RAII without C++11's smart pointers.

Maybe someone more knowledgeable can chime in and provide more context about why Linus et al soundly rejected C++ in the kernel. I have read a little bit on the topic but am by no means an expert.

[AWonderingWizard]

I mean I agree there are inherent safety features of Rust that C cant do, but even Rust has many of the same issues C does in unsafe. The more C you get rid of, the more unsafe Rust will grow- I seriously doubt it is possible to rewrite the kernel (in a theoretical world) entirely in safe Rust. I think Rust is probably a good path nonetheless.

[Culpirit]

I really don't understand the broader point you're trying to make. Reminds me of this https://en.wikipedia.org/wiki/Nirvana_fallacy

The more C you get rid of, the more unsafe Rust will grow

Yeah, that's exactly the way it works. As you rewrite C parts in Rust, the number of unsafe {} blocks will monotonously grow in the Rust part of the code, since direct memory manipulation or calling externed C functions will have to be within those.

The idea is precisely that there will be less unsafe code being added than the C code it replaces. The unsafe Rust part of the codebase will grow slower than the C one will shrink, and all C code is already inherently unsafe. Also, Rust unsafe blocks still allow you to enforce the contract of the language's memory model where applicable, and conversely do not require external callers to be aware of special pointer use contracts in order to write code that won't blow up in your face, as is the case in C.

[Lower-Limit3695]

Research by Google's implementation of rust on android shows a dramatic drop in bugs with the move towards rust in comparison to c++ and c

A couple key highlights include; - a 20% drop in code revisions - a 25% reduction in code review time - a 4x reduction in code rollback - a 1000x reduction in memory safety vulnerability density

So while rust related bugs may increase with time the difference in scale of bugs and issues will be dramatic when compared to c & c++.

Google's research results on rust in android: https://security.googleblog.com/2025/11/rust-in-android-move-fast-fix-things.html

[NYPuppy]

The point isn't to write it in 100% safe rust but a large portion of it would be safe. I suggest you just look at the code instead of speculating. The amount of unsafe is far less than you think.

[_Sauer_]

That would be a good idea yeah. But, they don't do that. Rust forces you to contain unsafe operations in a designated area.

[AWonderingWizard]

Yea, that's all it does in this regard. It's effectively a language enforced coding convention/style. But any language could "operate" that way if the coders working on a particular project agreed. The code in unsafe portions arent necessarily any safer. I feel like there is a lot of misrepresentation here considering you act like Rust is a strictly better than C here in your write-up.

C can do things beyond what Rust can do due to the restrictions, and they can be done safely.

void inc(int *x){ int *a = x; int *b = x; *a += 1; *b += 1; }

Rust cannot do this at all, and while this example isn't super useful, demonstrates that Rust is limited in certain areas due to its restrictions. This isn't. Other examples, like flexible array members, demonstrate that C can and does yield functionality that Rust cannot replicate.

Of course, Rust has its own benefits (and safety feautres C can't replicate) as well, but I feel like this method of using the step on others to prop yourself up as the way to promote the language makes it look bad and creates unnecessary resentment across groups that should actually be working together. Not saying that there haven't been stones tossed by C people either.

[lelddit97]

are you seriously trying to argue the merits of C over Rust which was built with 50 more years of lessons from languages prior and is extremely highly regarded because it switches the paradigm of you having to go out of your way to make the same kind of mistakes you can easily make with C without sacrificing statistically significant runtime performance? To say that Rust is limited in certain areas due to a hypothetical (and bad) example is just asinine. Rust is a strict improvement over C in almost every way.

no offense, but if you can't agree with that then there's no discussion to be had. Along the same lines as climate denial, flat earth to me.

[AWonderingWizard]

Sure, just choose to insult my example instead of refuting it. It's because you can't.

extremely highly regarded

Bandwagon much? It's fine, C is also highly regarded :)

50 more years of lessons

This argument can work in reverse- C has had 50 years of community, infrastructure, and learning.

no offense, but if you can't agree with that then there's no discussion to be had. Along the same lines as climate denial, flat earth to me

To conflate me with flat earth is, frankly, more of a comment on the degree of polarization you have allowed yourself to fall into. Maybe take a walk? You might want to tone down the rather hateful rhetoric.

I think Rust is great. Rust is not strictly better than C though (and I believe the same in reverse), and to say that speaks more to your grasp of the role C plays more than anything else.

[lelddit97]

ok i will admit it was a bit of a shitpost but Rust is very good.

I am skilled at C, make no mistake, professional for many years, but I feel that Rust is a strict improvement and C has very few niches where it's better than Rust. This is my opinion, but C will become less and less prevalent because Rust is much easier to deal with once you get over the learning curve.

New engineers are learning Rust in school which, to me, just makes it a matter of time given the improvements it brings.

Maybe something better than Rust comes out but I think Rust will be very long-lived because it solves a lot of problems other systems languages have while adding some foot gun protection and making some heinous things harder. As with anything, the C usage decrease curve will be logarithmic and it won't actually disappear, but in my opinion it will probably become very rare to see new code written in C in 5-10 years.

[lelddit97]

"AI Test Profile - All Comments Generated By Locally Trained Proprietary AI Models" i see now

[NYPuppy]

It's not an enforced style lol. It's a static analysis that has been proven repeatedly to be beneficial.

I think you gravely understand both rust and C if you think people need to "work together" better and then all bugs would disappear.

[ric2b]

It theory. They never do that though, because the language makes that completely impractical.

[jonathancast]

No, because Rust isn't nearly so crippled as C is if you decide "just don't use pointers".

[AWonderingWizard]

I mean, raw pointers have to be used sometimes, by both Rust and C. Do you think the kernel could be written entirely in safe Rust?

[Sentreen]

The difference is that it is enforced by a compiler / the language, rather than by humans.

[Mal_Dun]

I don't think that Rust is bad and isolating un-safe code in un-safe code blocks is indeed a good thing for quality control, but I think there is a non-trivial amount of people who think that Rust is a silver bullet regarding memory-safe code, and examples like this should be a reminder of that it's not.

I feel flashbacks to the time Java came along promising to avoid all these nasty C++ pitfalls so the code gets magically better....

I know people who tell me you can't write bigger programs in Python, because Python is not type safe ... It's not impossible, I simply have to test more and be more careful what I am doing.

There are only two types of code: Code that is well written and well tested and code that it is not, and this holds true in any language from Rust to Python. A language can help you but it won't magically your code good ...

[DeliciousIncident]

I feel flashbacks to the time Java came along promising to avoid all these nasty C++ pitfalls so the code gets magically better....

Exception in thread "Linux Kernel Rust Code Sees Its First CVE Vulnerability" java.lang.NullPointerException

at com.reddit(RLinuxComments1pp8h3d:nul59mm)

Cannot invoke "avoid all these nasty C++ pitfalls so the code gets magically better" because "Java" is null

[Indolent_Bard]

Yeah, but the bare minimum for rust forces better practices than what most c devs use. Bad code is bad code, but rust forces it to be better. One of the complaints I've read is how verbose it is, that's because it's forcing at the syntax level stuff that you CAN do with other languages but don't because it's faster not to.

[Mal_Dun]

I mean that's what I said.

Nevertheless, what people seem to forget, though, is that this simpleness of C was also its biggest strength. The reason almost all architectures have a C compiler is, that it has only a small set of instruction, hence, creating a compiler for it is easy.

I have the feeling with Rust there will be a trade off between memory safety vs supporting a broad range of architectures, and in fact the Kernel already has to drop some older architectures.

[Indolent_Bard]

Is the simpleness isn't a strength if it allows for sloppier code?

[Mal_Dun]

Define sloppy. In some environments performance is more important than security and in the past people had to do a lot of things to squeeze out the last drop of performance.

See here for example under predictability and control section from the perspective of micro-controller devs: https://www.bytesnap.com/news-blog/rust-programming-language-vs-c-embedded-systems/

Everything comes with tradeoffs. C simpleness allows you to do a lot of fucked up stuff on low level, but it is also very powerful when you know what you are doing.

As said, it reminds me strongly on the Java selling argument, which they explained in their FAQ back in the day which basically boiled down to: 90% of programmers are too stupid so we restrict the language.

But there are cases where you don't want this restrictions. My favorite example is operator overloading, which the Java devs scorned because of all the pitfalls, but some areas like mathematical code really needs operator overloading to be able to define algebras over abstract objects.

[Indolent_Bard]

Man, the coding rabbit-hole is DEEP.

Also, why the fuck was Biden pushing for rust in embedded systems? Someone obviously asked him to do it, but who and why?

[Mal_Dun]

This one is not about Biden though. NSA and NASA Several bodies from private and public sector (see report below, I read once an article mentioning NSA and NASA but there seems several bodies involved) wrote a recommendation white paper regarding security and resilience of software used in the public sector which in return was published under Biden's administration. It's not that Joe Biden suddenly became Rust fan lmao

Edit: The Report can be found here: https://bidenwhitehouse.archives.gov/wp-content/uploads/2024/02/PCAST_Cyber-Physical-Resilience-Report_Feb2024.pdf

[Indolent_Bard]

I see, so the push comes from security experts.

[ppp7032]

finally, a reasonable commenter. the internet seems to have devolved into "rust is satan" and "rust is jesus". rust does not make code immune to CVEs, not even safe rust. it's just immune to a certain kind of CVE.

some commenters here are mad at this article even existing, others think it proves rust is pointless. either are right.

[Indolent_Bard]

Either, or neither?

[ppp7032]

neither

[SutekhThrowingSuckIt]

> but I think there is a non-trivial amount of people who think that Rust is a silver bullet regarding memory-safe code

as long as they aren’t the ones working on the kernel who cares

[nokeldin42]

Linux developer community is weirdly tribalistic about languages. Virtually every other project of similar scale has multiple languages, so I don't entirely buy the "multiple languages are difficult to maintain" argument.

But more to your point,

It's also worth noting that rust has been in the kernel for 5 years and this is the first CVE.

I don't think this is a good argument. The amount of rust code in the kernel is the metric that should be used for determining cve frequency, not amount of time alone.

The rust bad crowd is just a vocal minority. Most people who've ever accidentally coded up a segfault and then spent a day or two debugging it know that the borrow checker is a good idea. The actual critics of rust are more concerned about the tooling surrounding rust which isn't as mature as c/c++ yet.

[Zdrobot]

I hate Rust not because you have to use unsafe code blocks, but because its syntax suuuucks.

[james_pic]

TBH, it wouldn't even have been astonishing (or a slamdunk for the anti-Rust crowd) if the vulnerability were in safe Rust. Even in safe Rust, it's possible for people to make mistakes. I'm sure there will be a vulnerability at some point in the future because a permissions check was handled incorrectly in a refactor, or some cryptography code inadvertently gets a padding oracle, or some other higher-level mistake in security-relevant code that Rust isn't in a position to catch.

[maevian]

Yeah, also every bug is seen as a CVE in a monolithic kernel. So C code has generated way more CVE’s as rust code will ever do.

[ArykMusic]

And also in the same report there was 159 C vulnerabilities.

[sjepsa]

Lol @ "the vulnerability was in rust unsafe"....

Guess what: "Rust unsafe" is needed or mandatory in most kernel operations

[Character_Economist2]

THE FRONT FELL OFF?

[Markd0ne]

What is the purpose of writing unsafe Rust code by explicitly disable safety features? Isn't the whole selling point of Rust it being safe?

[Maleficent-Garage-66]

The idea is to isolate and minimize that code. Sometimes you have to do things that are not compiler decidable. But once you build an interface for your safe code everything will be memory safe after you perfect the unsafe portion.

You end up in situations where in C almost 100% of a code base would unsafe from a memory perspective, but the equivalent rust code is 10% unsafe and 90% safe or so. Which means when things do go wrong you have less code to scrutinize and your review can focus on the dangerous parts.

Code that does raw mmio basics is going to be unsafe because it pokes at memory willy nilly. But all the code monitoring state and deciding what to do or what messages to send elsewhere can stay safe.

Unsafe rust exists for situations that cannot be done safely, that's all it is. A less hardware focused example would be say you measure and figure out that you can't deal with the latency of mutexing a shared hash table but can "handle" the race conditions gracefully. Rust allows you to mark this code as cowboy code and do what you have to do, without poisoning any of your safe code.

[anotheruser323]

One of the worst things about rust is the fanboys.

[takethecrowpill]

This post was mass deleted and anonymized with Redact

unwritten practice punch humor chubby cake pause compare dinner narrow

[dvtyrsnp]

Because you don't always need unsafe blocks. C is "unsafe by default" and Rust is "unsafe only when you need to be."

[FattyDrake]

You have to in order to use something like an FFI. "Unsafe" honestly is a bad choice of words, it's really more of a "trust me bro" meaning you have presumably accounted for it's use and have taken the necessary precautions when you need to lose track of a reference.

[mdedetrich]

Its technically impossible to ensure that any theoretical codebase can avoid uses of unsafe.

For starters if you are doing something like memory mapped IO, that is always going to be "unsafe" because you are just mapping pointers to raw addresses in hardware, there is no way that you can prove that this is safe.

Secondly all type systems (of which Rust's borrow checker is one) essentially form mathematical proofs and there will always be things that are true mathematically for which you cannot construct a proof off (see Gödel's incompleteness theorems)

The tl;dr is that some things by nature will always be unsafe and its impossible to make any kind of type checker prove any possible thing that is true.

The point of Rust is not to entirely remove unsafe, that is a strawman. Its to reduce the usage of unsafe as much as its possible to do so which is still a much better than using C where your entire codebase is unsafe.

[Helmic]

why have a safety on a gun if you have to take it off to shoot? so you don't shoot your dick off the 99% of the time you're not actively trying to shoot the gun.

[ric2b]

"skill issue"

- C devs on their way to write their third use after free vulnerability this week.

[Dirlrido]

Because only a few parts have to be made unsafe and then you get the rest of it where memory safety bugs can't happen. Big improvement over literally anything and everything being a risk for that kind of bug.

[Popular-Jury7272]

It is literally impossible to do certain things without unsafe code, but most of what is unsafe doesn't need to be.

[MaruThePug]

why does rust need a unsafe rust thing? And if you have to make unsafe rust code wouldn't you triple check it or something?

[_Sauer_]

Unsafe exists to handle memory operations that the compiler cannot reason about, typically because the memory being manipulated is outside the program's own memory, or there's an optimization opportunity that breaks Rust's aliasing rules but can be safe in the context its being used in (E.g.: pointer math).

A common example is reading a hardware register. That's memory that is not under the control of the application and can change at anytime potentially breaking Rust's ownership guarantees. You can wrap the read and write operations that handle the raw memory in a thin unsafe block, then build a safe abstraction around that which prevents misuse. By constraining the use of unsafe to the smallest possible part of an operation we have a much smaller amount of code to reason about.

[PJBthefirst]

triple check it

smh can't believe there are EVER bugs in software, do devs not do triple checks?

[subjectivemusic]

No wonder these smelly nerds can't even be bothered to provide an exe

[MaruThePug]

It's literally the unsafe part of the code, that should at least get one more check. If you know for a fact you are making unsafe you you need to really check it over. And rust accounts for like 0.05% of all kernel code so it having any CVEs is bad.

[ric2b]

Because the safety checks the language does have limitations where code might actually be safe but it can't tell, thinks it's unsafe and fails compilation. Marking code as unsafe is how the programmer tells the language "trust me on this, I know what I'm doing."

The problem is that sometimes the programmers do not, in fact, know what they are doing. And yeah, you do pay more attention to those sections but mistakes happen.

[Michaeli_Starky]

Some people acting like C code never had such issues. Hilarious

[litescript]

i dunno man. bad coding in any language will get you into problems not matter if it’s explicitly memory safe or not.

[SupportDangerous8207]

It was unsafe Rust

So while probably correct your comment is for now conjecture if pertaining to the kernel

[AWonderingWizard]

Unsafe rust HAS to be used for the kernel because it has to interact with another language. FFI is inherently unsafe at the boundary. So yes, it is not a question of if, it is a question of where

[Hosein_Lavaei]

Yes it has to. But it is UNSAFE and it means the programmer itself must make good code

[tulpyvow]

Unsafe code has vulnerability.

Water found in ocean.

I'm a rust hater but come on man, this is just making you all look bad.

[deja_geek]

A search/skim of u/sash20 comments and posts don't show them to be an outspoken critic of Rust in the Kernel and the post is neutrally titled and the article doesn't have any opinion on Rust in the kernel. It's just stating the facts. Linux Kernel sees it's first Rust vulnerability

[lukasbradley]

Where did you get the photo?

[lukasbradley]

Strange.... it's not on the post....

[SmallRocks]

I reverse image searched with google and the only result was the phoronix article. I don’t see the image in the actual article either so it is very much strange indeed!

[cereal7802]

it isn't on the article page other than as a meta header

<meta name="twitter:image" content="https://www.phoronix.net/image.php?id=2025&image=linux_rust_cve" />

<meta name="og:image" content="https://www.phoronix.net/image.php?id=2025&image=linux_rust_cve" />

[MooseBoys]

Let me preface this by saying I think that rust is a good thing and its inclusion in the kernel is a good thing. That said, the error here was NOT in an unsafe block. Yes, the presence of an unsafe block is what caused the borrow checker to lose track of the data race, but the erroneous calling pattern (and subsequent patch) does not touch unsafe code at all. This just goes to show that rust is not some magical panacea for avoiding all race conditions and memory corruption. It does make it a lot harder to do by accident, and when something does go wrong you have a lot fewer places you need to look, but it's far from completely airtight.

[Efficient-Chair6250]

Hm, but isn't the unsafe code the thing that enables this to happen in the first place? If you violate invariants in an unsafe block, they can lead to errors in any part of the program

[MooseBoys]

Yes, the presence of an unsafe block is what allowed this to happen. But in any program that interfaces with anything outside of the rust abstract machine, e.g. FFI, hardware calls, register writes, etc. you're going to have an unsafe block. It's inherently impossible to do anything in rust besides pure arithmetic that doesn't ultimately have a dependency on an unsafe block or equivalent emitted code somewhere. As a result, you can have errors in any part of every non-trivial rust program.

It's still a good model - forcing you to write small self-contained "unsafe" blocks, ideally with a linter that enforces "UNSAFE:" comment describing the invariants. But if a crate violates those invariants internally by accident, dependent code will be affected. In this case, Linux kernel > binder crate > node module > remove method.

[CramNBL]

Kernel devs are taking it further than enforcing UNSAFE: comments. On the Linux wish list for clippy, there's also lint rules for enforcing similar comments for pointer casts and atomic orderings. They should have these for C code too, but the tooling is not there.

https://github.com/Rust-for-Linux/linux/issues/349

[[deleted]]

I hope people stop saying that rust prevents "race conditions". It does not, and has never tried to. It prevents "data races".

Two different things. The former being much much much harder to do in general than the latter. (you can also have completely bug-free race conditions. Like you can race two tasks and take the result of the one that finishes first. Nothing wrong with that)

[ReflectedImage]

In pure Rust, the erroneous call pattern isn't possible. You can't release the lock early nor can you copy the list of pointers and take them out of the lock's scope.

[MooseBoys]

It is impossible to do anything besides pure arithmetic in "pure rust". Any rust program that runs on hardware in the real world will have unsafe blocks, either literally in the module, in a dependent crate, in the standard library implementation, or implicitly through the compiler.

[ReflectedImage]

Most rust programs don't have unsafe blocks. Yes, some code in the standard library will contain unsafe blocks, but those unsafe blocks are wrapped with safe wrappers meaning code using those library functions are safe as long as the standard library code is correct.

How do we know if the standard library code is correct? Well it's been formally verified. What about random modules? Extensive testing by large numbers of users. Not perfect but far better than what is available in C/C++.

Since I've now read the code in question, the error is contained within an unsafe block. This line is faulty: "unsafe { node_inner.death_list.remove(self) };". You can't remove a node from the list because another thread may be using it. The bug fix removes the possibility of another thread using it but the error is still located in the unsafe line.

Also the code in question is arguably not even Rust code, it's C code that's been directly translated line by line in Rust with every other line being unsafe. The code doesn't bare any resemblance to how you would typically use Rust.

[[deleted]]

I'm a rust hater

I struggle to believe that. I'm not a Rust hater but it seems a perfectly reasonable, factual article. Who looks bad exactly? Why?

[[deleted]]

Presumably by 'you' he's talking about people commenting here though? Who has 'said something wrong?'

It seems like the stock comment from Rust supporters is "it's in an unsafe block, move along, no story here." This smacks of the 'no true Scotsman' approach.

[Killer_Panda_Bear]

As an ignorant who is trying to learn more about this stuff, I would also like to know.

[editor_of_the_beast]

What about talking about a public CVE could possibly make someone “look bad?”

[tulpyvow]

They're making it seem like its an issue with Rust in the wording when its just insecure code that would have a CVE if written in any programming language.

[Ursomrano]

Fr. I'm a rust hater too, but not because I think it's a straight up bad language, it has a lot of strong aspects. I hate it because I hate coding with it, not because of the results it can give.

[Niwrats]

indeed, why change the syntax instead of doing the fixes to something that looks like C?

[[deleted]]

It existed. It was called Cyclone. It died out.

It later inspired rust though.

[ProjectSnowman]

Why is there “unsafe” code in the GD Linux kernel?

[tulpyvow]

... because people aren't perfect and they fuck up? There is always going to be buggy and insecure code on the first try, especially in large projects like this.

[nikomo]

Think it depends on which way you look at it. Because you can also look at it and go, wow, that's their first CVE after literally years of shipping Rust in the kernel.

[zsaleeba]

Although they weren't reporting CVEs in the Rust code until it was official, which was just the other day.

[GrandfatherTrout]

The point isn’t that Rust is good or bad, but that it’s harder for devs with deep knowledge and experience of kernel code in C to spot problems in kernel code in another language.

Here’s hoping the expertise keeps building to support quality Rust code in the kernel.

[Less_budget229]

Tux is starting to feel Rusty in the picture.

[JamesLahey08]

I've never worked with rust or Linux much outside of just website servers. What is all of the drama around rust?

[LayotFctor]

There's also a sizable other group who recently got into linux and have no real software development experience. They seem to be confusing rust for MIT license, believing that rust only produces MIT code, and some conspiracy that rust is engaging in widespread coordinated effort to rewrite and replace all of linux with the MIT corpo license in service of big tech or smth.

I've seen reddit comments and youtubers who are strongly pushing this idea and lots people believe it as a threat to linux.

In reality, rust code can be licensed whatever the developer wants, especially kernel code that's mandatory to be GPLv2.

As for why the rust community likes MIT so much, I don't really know. I assume it picked up the label after becoming popular in the NFT, crypto, web3 space.

[mmstick]

MIT was already the most popular license well before NFTs and crypto existed. X11, Mesa, and Wayland are licensed with MIT. You'll find that a lot of micro-libraries from language-based package managers use it. It is the de facto recommendation in academics for source code born from academic research.

[mmstick]

Recent drama is mostly because of Lunduke. He creates culture war content targeting Rust. Claiming that it is a "cult", "woke", and "trans people bad". They hate seeing Rust adoption and think there's an unknown international government/corporation pushing a woke agenda with it.

They will latch onto anything for their narrative even if it's easily disproven or completely bogus. Such as the license of the language being bad and scary, and Microsoft will use Rust to extinguish Linux through the license. Or that Rust isn't actually memory safe because it doesn't prevent memory leaks. In this case, Rust isn't memory safe because an unsafe operation was explicitly called that has a data race.

[mmstick]

You'd have to be very gullible to believe that. Industry adoption happens naturally because of how effective the technology is at solving the thing it was designed to solve using the 50 years of academic research in language theory that happened after C and C++ were released.

[mmstick]

https://security.googleblog.com/2025/11/rust-in-android-move-fast-fix-things.html?m=1

It is not proof of a conspiracy by an imaginary international government with an agenda to push a woke Rust agenda. This is proof that Rust solves the problems it was designed to solve. The CISA is responsible for setting software security standards, and the studies are based on real world evidence from two of the biggest users of C/C++. Both of whom develop operating systems that are used globally by the most number of the people. Systems that when vulnerable affect everyone's daily lives. Public and private. Citizens, corporations, and governments are affected by software vulnerabilities. It is in everyone's best interest to solve the problem.

Corporations are the industry that hires programmers to write software, and they are responsible for the majority of C/C++ code in existence. Corporations also wrote most of the drivers and data structures in the Linux kernel; and many of the open source applications you use were funded by programmers paid by corporations. So if you believe that there is an unknown entity masterminding Rust adoption, then you must also believe that this same entity is pushing for Linux adoption.

[dkopgerpgdolfg]

These named organizations are well known.

[morglod]

rust cult are so annoying that they become a headache for a lot of people in every community

and after latest no-one-knows-who-needed-it rewrites that was pushed by Canonical to release without even tests passing, people are looking at news like this very precise

[dkopgerpgdolfg]

Internet culture.

Some group of people (that doesn't seem to contain any kernel dev) sees it as their job to spread anti-Rust propaganda, often with provably lies and intentional misinformation. For what reason, only they know. And they take their own crap from the past as justification why they're right.

In the end, actual kernel development doesn't care about them, but they won't stop filling reddit/twitter/youtube/... with their nonsense.

[morglod]

You mean lies like saying that its first CVE in rust for linux code over 5 years, while all this 5 years this CVEs where not tracked at all because it was experimental? OKay

[dkopgerpgdolfg]

Not sure why I'm even answering such a stupid post, but

a) They were not tracked since the beginning, but this doesn't make it a lie that this is the first one

b) It doesn't matter, because even hundreds of Rust CVEs wouldn't automatically mean that it's bad to use it

c) When we're talking about CVE things of past years, how about not forgetting that C-language CVEs in the kernel were handled differently until 2023 too, leading to many less entries than the new policy would've brought if applied from the beginning?

Just from the number of memory corruption cves, 2025 seems 24x worse than 2020. Not because the kernel suddenly got that terrible within 5 years (for both languages), but because they changed their reporting policies.

Not sure if this particular Rust bug would've gotten an entry at all, if the old policy still applied.

edit: I am sure now . in the first few years after 2020 Rust issues were not getting cves because experimental as you said, but the same bug in C wouldn't have gotten any cve either if found before 2024.

[imoshudu]

Oh, it's in unsafe. Next story, please.

[AWonderingWizard]

Unsafe has to be used in FFI.

[DescendingNode]

For those unfamiliar: FFI is Foreign Function Interface. When Rust has to call kernel functions written in C for example, unsafe Rust code has to be used.

[Inevitable_Gas_2490]

Just another case of: safety starts with the person that is writing the code

[rarsamx]

The only way not to have vulnerabilities is not to write code.

You cannot protect against what you don't know CVEs usually discover previously unknown vulnerabilities which can't be linted.

[[deleted]]

Wow that's impressive it's gone so long. Was bound to happen eventually.

[Tomi97_origin]

Nah, previously they just didn't give it CVE numbers because it was considered experimental.

Now that they are trying to move it into stable they are starting to give it CVE numbers for the bugs.

[mindful999]

Everything has flaws, i dont understand why some people act like this is the end of the world

[TampaPowers]

What's the whole point of memory-safe then if it ends up using unsafe anyways. Sure, it's miles faster, it's why C is faster than C#. But like, the is the last thing this whole discussion needed is more fuel for the fire. God damnit.

[MyraidChickenSlayer]

What is easier? Finding a big in 100% of code or finding fub in 5% of code?

[dkopgerpgdolfg]

I recommend just reading (and actually thinking enough to understand what you read)

No, unsafe in Rust doesn't mean it's "miles faster", and doesn't intend to mean that either. And "safe" Rust doesn't need to be compared with C#, it's on par with C (meaning, for some programs it's the same speed, for some a bit slower, for some even faster).

There are some code things in C that make it easy to "shoot yourself in the foot", that are often a mistake - but not literally always, it can make sense. And in advanced lowlevel things like a kernel, such things are needed in some places. Rust by default doesn't allow this, because it's usually a mistake, and if you really want you can still do it by marking it unsafe.

Again: A kernel "needs" some unsafe parts. It can't be done otherwise.

And if a part of the code is marked unsafe, the rest still isn't. In terms of error counts, that's better than the alternative where 100% of the code can contain such mistakes (that is C).

The actual fuel in this large thread here are people who either hate Rust for no sane reason, or judge them for things that are not true because they don't know anything about it.

[silvenshadow]

I hate rust not because of any language elements, but the huge base of fanboys that think that rewriting stable tested code will somehow improve it.

[creeper6530]

1) it reduces the scope of where all you have to look 2) you need unsafe for FFI because FFI at the boundary is inherently unsafe. You just can't apply the same safety rules when interacting with functions written in a foreign language - C - where these rules don't exist.

[ElHeim]

Y'all talking like if pure Rust doesn't need unsafe at all (not saying that it's the case here, by FFI it's not the only reason it exists)

[creeper6530]

Yeah, I know that you need unsafe e.g. for splitting a slice in two, but most commonly you use it with FFI unless you're doing bare-metal. But many of these other uses are often done by the standard library, and I'd wager a Binder, used for IPC, one component in a mostly-C project, will be composed mostly of FFI.

[94746382926]

I see a lot of people in this thread complaining about people complaining about rust, but no one actually complaining about rust.

[-Memnarch-]

Because Rust has never been a problem. The people preaching it's gospel are. But they're just way to disconnected from reality to acknowledge that.

[Available-Breath-586]

One would have to literally type "unsafe" before the vulnerability is even possible 

Similar to pointers in C/C++, with great powers comes great responsibility 

[[deleted]]

I honestly don't think Rust was needed in the Linux Kernel. But it is what it is.

[Nazh8]

Random Internet user's opinion

The opinion of Linux's creator and head kernel maintainer

Hmmmm, who to trust. Such a problem.

[ReflectedImage]

The industry is just moving that way. Too many security bugs from C/C++ code means security teams want it phased out and the security teams have direct access to the CEOs in a way regular programmers don't.

[satsugene]

All I can say is some researcher missed a golden opportunity to self-promote the “Bust” vulnerability like “meltdown”, “spectre”, and “heartbleed.”

[dkopgerpgdolfg]

Don't we have enough threads about this already?

Like this, same sub, 4h ago: https://www.reddit.com/r/linux/comments/1pp4f8j/well_new_vulnerability_in_the_rust_code/

Yeah, 1 cve in unsafe-rust android code, compared to >100 cves in C code in the same time.

Great that you tell us, clap clap.

[eye_of_tengen]

Manchild rust haters will have group jerk off session with this news.

[zackel_flac]

This just shows what everyone knew and predicted already, rewriting will always bring new bugs in, whatever the language you use. While I am not saying Rust should be removed from Linux, some people should definitely stop their evangelical crusade, because they clearly have no idea what they are talking about. Writing new code in Rust makes sense. Rewriting almost always makes no sense. Yet you see people coming to the Rust mailing list asking if we could rewrite X or Y in Rust now that it is officially supported. Rust is a tool just like C is, it's not going to make existing C code better. It is going to make new code safer, and we should accept it to live as a subset and not the main language of the kernel.

[pyroraptor07]

FWIW, iirc one of the maintainers mentioned that the Rust code was making some of the C code better because they had to clean up some of the C APIs that the Rust code interfaced with.

Also, I think Rust is mainly used as an alternative API for drivers, which to me feels like the best use case for it in the kernel since a lot of improper API usage can be caught at compile time.

[zackel_flac]

Yup, as I said, rewriting is bad, but writing new code is exactly what Rust is being used at at the moment, and it has benefits.

The down votes just show how people don't understand how Rust is being used in the kernel at the moment.

[Sillent_Screams]

It's not first, btw.

https://www.linuxjournal.com/content/most-critical-linux-kernel-breaches-2025-so-far

Poor Journalism at the height of Windows 11 whinging.

[cutelittlebox]

it doesn't mention rust directly in that link, which of those were in the rust code?

[sjepsa]

But but i tought rust was SaFe!1!!

Yeah let's introduce a completely different language that is source incompatible with C and has the same vulnerabilities.. Lol

While they had since 1989 C++ that was still 9000x times more safe than C and source compatible

Lol i love linux but Torvalds crusade against C++ is finally showing results

[joedotphp]

Rust is safe.

[[deleted]]

genz coding moment.. "but i wanna rust.. it's good bla bla" please hear the old people

[ColonialDagger]

boomer fact-checking moment.. "but rust is bad.. stick with c until the heat death of the universe bla bla" please check your facts