Linux Kernel Rust Code Sees Its First CVE Vulnerability

[erek]

"This first CVE for Rust code in the Linux kernel pertains to the Android Binder rewrite in Rust. There is a race condition that can occur due to some noted unsafe Rust code. That code can lead to memory corruption of the previous/next pointers and in turn cause a crash.

This CVE for the possible system crash is for Linux 6.18 and newer since the introduction of the Rust Binder driver. At least though it's just a possible system crash and not any more serious system compromise with remote code execution or other more severe issues.

More details on CVE-2025-68260 via the Linux CVE mailing list."

Source: https://www.phoronix.com/forums/for...el-rust-code-sees-its-first-cve-vulnerability

 

[Zarathustra[H]]

I didn't know that they had actually done this. Last I was reading up about it, Linus seemed pretty skeptical about letting Rust into the Linux kernel but this was several years ago. more recently his stance seems to have softened a little, but some of the traditional senior kernel developers like Hector Martin and Christoph Hellwig were very opposed to it, Hellwig famously calling mixed language projects like the resultant C and Rust output a "cancer" and Martin resigning with some vague posts on social media referencing Rust. Hellwig later reduced his role in Kernel development as a result as well...

I thought this drama had pretty much ended the "Rust in the kernel" experiment.

Proponents of Rust have touted it being better at avoiding memory management issues (but honestly, it wouldn't take much to be better at that than C). Opponents to its inclusion in the kernel seem concerned about its interaction with the legacy C portions of the kernel and difficulties in managing multi-language projects as a potential source of serious issues.

My understanding is that in order to make Rust's capability to reduce memory management failures requires completely refactoring the code architecture in a way that is not required in C. Many see this as a needless and inefficient complication, needless because these memory managements shouldn't happen anyway, as they are bugs, and when they do happen, they should be fixed. There is no doubt that some of this has to do with a reluctance when it comes to change. It happens to all of us at some point. But that doesn't mean that their technical arguments are wrong.

I guess this failure is proof that just because Rust manages memory better doesn't mean you won't have serious issues.

 

[LukeTbk]

last year,
View: https://youtu.be/0bb3-bjgf88,

I wonder what changed his mind?

the way he talk he needed to be actually proven by people willing to maybe work into something that will never be used for years in a parallel sandbox before letting it go into production, which happened.

 

[uOpt]

WTF is "Android Binder"?

 

[LukeTbk]

WTF is "Android Binder"?

they do in details in the article: https://www.phoronix.com/news/Rust-Binder-For-Linux-6.18

Binder is a critical part of Android for inter-process communication (IPC)
1. Complexity: Binder is at the intersection of everything in Android and fulfills many responsibilities beyond IPC. It has become many things to many people, and due to its many features and their interactions with each other, its complexity is quite high. In just 6kLOC it must deliver transactions to the right threads. It must correctly parse and translate the contents of transactions, which can contain several objects of different types (e.g., pointers, fds) that can interact with each other. It controls the size of thread pools in userspace, and ensures that transactions are assigned to threads in ways that avoid deadlocks where the threadpool has run out of threads. It must track refcounts of objects that are shared by several processes by forwarding refcount changes between the processes correctly. It must handle numerous error scenarios and it combines/nests 13 different locks, 7 reference counters, and atomic variables. Finally, It must do all of this as fast and efficiently as possible. Minor performance regressions can cause a noticeably degraded user experience.

 

[Nobu]

I didn't know that they had actually done this. Last I was reading up about it, Linus seemed pretty skeptical about letting Rust into the Linux kernel but this was several years ago. more recently his stance seems to have softened a little, but some of the traditional senior kernel developers like Hector Martin and Christoph Hellwig were very opposed to it, Hellwig famously calling mixed language projects like the resultant C and Rust output a "cancer" and Martin resigning with some vague posts on social media referencing Rust. Hellwig later reduced his role in Kernel development as a result as well...

I thought this drama had pretty much ended the "Rust in the kernel" experiment.

Proponents of Rust have touted it being better at avoiding memory management issues (but honestly, it wouldn't take much to be better at that than C). Opponents to its inclusion in the kernel seem concerned about its interaction with the legacy C portions of the kernel and difficulties in managing multi-language projects as a potential source of serious issues.

My understanding is that in order to make Rust's capability to reduce memory management failures requires completely refactoring the code architecture in a way that is not required in C. Many see this as a needless and inefficient complication, needless because these memory managements shouldn't happen anyway, as they are bugs, and when they do happen, they should be fixed. There is no doubt that some of this has to do with a reluctance when it comes to change. It happens to all of us at some point. But that doesn't mean that their technical arguments are wrong.

I guess this failure is proof that just because Rust manages memory better doesn't mean you won't have serious issues.

To be completely memory safe, you can't use any "unsafe" code. But writing hardware drivers and the like generally requires writing "unsafe" code. There are some other benefits of rust, but I don't think they are exclusive to the language, at least not all.

 

[WhoBeDaPlaya]

This raises the requirements for bootstrapping Linux on new / unsupported architectures
Now have you have to make both gcc and Rust for the new target

Kind of like the joke about vegans; how do you know someone uses Rust? Don't worry, they'll tell you!

 

[DanNeely]

I didn't know that they had actually done this. Last I was reading up about it, Linus seemed pretty skeptical about letting Rust into the Linux kernel but this was several years ago. more recently his stance seems to have softened a little, but some of the traditional senior kernel developers like Hector Martin and Christoph Hellwig were very opposed to it, Hellwig famously calling mixed language projects like the resultant C and Rust output a "cancer" and Martin resigning with some vague posts on social media referencing Rust. Hellwig later reduced his role in Kernel development as a result as well...

I thought this drama had pretty much ended the "Rust in the kernel" experiment.

Far from it:

https://lwn.net/Articles/1049831/

The (successful) end of the kernel Rust experiment​

[Posted December 10, 2025 by corbet]

The topic of the Rust experiment was just discussed at the annual Maintainers Summit. The consensus among the assembled developers is that Rust in the kernel is no longer experimental — it is now a core part of the kernel and is here to stay. So the "experimental" tag will be coming off. Congratulations are in order for all of the Rust for Linux team.

 

[DooKey]

As software becomes more popular, it becomes a bigger target for the black hats. Simple really. Nothing is safe.

 

[LukeTbk]

Now have you have to make both gcc and Rust for the new target

I think they are working on a gccrs to not need LLVM to work on the target, but not ready yet. Right now they have a fallback (rustc_codegen_gcc, https://github.com/rust-lang/rustc_codegen_gcc)
The primary goal of this project is to be able to compile Rust code on platforms unsupported by LLVM. A secondary goal is to check if using the gcc backend will provide any run-time speed improvement for the programs compiled using rustc.

You can also go full LLVM with no GCC now.

There is a bit of nice turn of the tide, to have Linux kernel use Apple (and a lot of Microsoft-Google) LLVM and Apple/Microsoft use Linux so much