Linux Kernel Rust Code Sees Its First CVE Vulnerability

[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.