Conversation
Greg K-H
gregkh
Rust is is not a "silver bullet" that can solve all security problems, but it sure helps out a lot and will cut out huge swatches of Linux kernel vulnerabilities as it gets used more widely in our codebase.
That being said, we just assigned our first CVE for some Rust code in the kernel: https://lore.kernel.org/all/2025121614-CVE-2025-68260-558d@gregkh/ where the offending issue just causes a crash, not the ability to take advantage of the memory corruption, a much better thing overall.
Note the other 159 kernel CVEs issued today for fixes in the C portion of the codebase, so as always, everyone should be upgrading to newer kernels to remain secure overall.
That being said, we just assigned our first CVE for some Rust code in the kernel: https://lore.kernel.org/all/2025121614-CVE-2025-68260-558d@gregkh/ where the offending issue just causes a crash, not the ability to take advantage of the memory corruption, a much better thing overall.
Note the other 159 kernel CVEs issued today for fixes in the C portion of the codebase, so as always, everyone should be upgrading to newer kernels to remain secure overall.
2
109
167
Nik | Klampfradler 🎸🚲
nik@toot.teckids.org
@gregkh I'm pretty sure now that Torvalds goes all in on vibe coding, Linux will get the bad Rust code it deserves rather sooner than later.
0
0
0
penguin42
penguin42@mastodon.org.uk@gregkh Oh well, it's in an unsafe { } block, so all bets are off!
1
0
0
@penguin42 @gregkh Rust's type system persists into `unsafe` blocks, including e.g. lifetime checks. The remove function itself depends on two lifetime-bound entities and relies on the fact that the references are real to prove certain operations are correct to perform.
The problem is the safety requirement for this function is "leaky", because it includes a requirement about *other* lists. This safety requirement was one chosen by the kernel programmers, though, not Rust.
1
0
0
0
0
0