The Numbers Tell a Story of Momentum, Not Hype
When Rust support landed in the Linux kernel as part of version 6.1 in late 2022, the actual codebase contribution was modest: roughly 13,000 lines of infrastructure, bindings, and experimental abstractions. At the time, many of us in the kernel community treated it as a respectable proof of concept. We had been burned before by language experiments. We were cautious.
Fast forward to early 2026, and the picture has shifted enough to warrant serious attention. The kernel now contains over 600,000 lines of Rust code spanning drivers, filesystem abstractions, and core subsystem bindings. That is not incremental growth. That is exponential acceleration. What changed is not the language itself, which remained remarkably stable. What changed is that people started building real things with it, and those things started working.
The Nova GPU driver for NVIDIA open-source firmware is the highest-profile example of this shift. Linus Torvalds explicitly acknowledged in a December 2025 kernel mailing list post that Rust driver contributions have accelerated, singling out Nova as evidence that all-Rust driver efforts are no longer theoretical exercises. When the maintainer of a system as conservative as the Linux kernel validates a language transition at that scale, it is worth understanding what actually happened beneath the headlines.
Memory Safety Is Not a Philosophy, It Is a Bug Fix
The central argument for Rust in the kernel has never been about elegance or modernization. It has always been about preventing entire categories of security vulnerabilities from existing at the code level. That argument used to feel theoretical. Now we have data.
A 2025 study from the University of Waterloo analyzed 150 kernel CVEs spanning 2020 through 2024 and found that 67 percent of them fell into memory safety categories that Rust’s ownership model structurally prevents. That means two-thirds of the vulnerabilities that occupied kernel maintainers, security researchers, and patch management systems for five years could not happen in Rust. Not “might be less likely.” Could not happen. That distinction matters when you are managing millions of devices.
Google’s Android team provided complementary evidence from the other end of the supply chain. Their 2025 blog post reported that the proportion of new Android OS code written in memory-safe languages reached 77 percent, with Rust accounting for the majority of systems-level additions. More importantly, memory safety vulnerabilities in Android dropped to below 24 percent of total CVEs for the first time. That is not correlation being mistaken for causation. That is a team with massive institutional resources saying: we measured the outcome, and it worked. You can read their full analysis on the Google Security Blog on memory safety in Android.
The Abstraction Layer Problem Is Real, and It Matters
This is where the kernel mailing list drama of late 2025 gets instructive rather than merely entertaining. Ted Ts’o, a veteran C maintainer with decades of kernel work and the primary architect of ext4, posted a detailed technical critique that reignited the debate over Rust abstractions. His concern was specific and worrying: Rust’s abstraction layers were creating hidden performance regressions in I/O paths that conventional benchmarks were not capturing.
Ts’o was not arguing that Rust is fundamentally wrong. He was arguing something more subtle and more dangerous: that the language’s safety guarantees come with abstraction costs that developers do not always see, and that these costs can accumulate in the critical paths where microseconds matter. A filesystem driver might pass benchmarks while introducing latency jitter that only manifests at scale, under specific access patterns, on real hardware.
The reason this matters is that the kernel community does not tolerate invisible performance regressions. The kernel is not an application. You cannot simply add another gigabyte of RAM and call the problem solved. The kernel runs on embedded systems with 512 megabytes total. It runs on servers processing millions of transactions per second. It runs on your phone deciding whether your camera opens in 500 milliseconds or 2 seconds. Hidden costs accumulate.
This is not an argument against Rust. It is an argument for honesty about what the language trades. The counter-arguments have been equally substantive: that Rust developers writing for the kernel have learned to work within these constraints, that the abstraction layers are getting thinner, and that the safety gains outweigh the abstraction costs at the scale where the kernel actually operates. Both positions have merit, and that is precisely why the debate matters.
Reading the Mailing List Drama for Signal, Not Noise
The kernel mailing list has a reputation for intensity, and Rust discussions have provided no shortage of heated exchanges. But beneath the surface drama, something useful is happening: the kernel community is learning how to integrate a new language at scale while maintaining the standards that have kept Linux stable for three decades.
The fights over Rust abstractions, performance implications, and documentation standards are not failures of the integration process. They are the process itself. The kernel community is collectively debugging the right questions: How do you maintain visibility into what Rust abstractions actually cost? How do you prevent safety features from becoming cargo cult patterns that developers use without understanding? How do you build bridges between C maintainers with deep subsystem knowledge and Rust developers who may be new to kernel work?
These questions have ugly answers sometimes. Some subsystem maintainers have rejected Rust contributions outright. Some decisions have been made through contentious votes rather than consensus. But these are the growing pains of institutional change, not evidence of failure. The kernel survived the transition from monolithic to modular architecture. It survived the move to preemptible kernels. It survived becoming a hypervisor. It will survive becoming a multilingual codebase.
What Actually Matters Now
If you are trying to understand whether Rust in the Linux kernel is a success or a catastrophe, you are asking the wrong question. The real question is narrower and more useful: for specific subsystems with specific constraints, does Rust solve problems that C cannot solve as well? The data suggests yes, particularly in drivers, memory managers, and code that needs to be bulletproof against fuzzing.
The Linux kernel Rust documentation reflects this pragmatism. It does not argue that Rust should replace C everywhere. It documents specific patterns, specific constraints, and specific ways to write Rust that integrates cleanly with the C kernel. That is maturity talking.
Two years of merge commits have taught the kernel community something valuable: major architectural changes do not happen through convincing arguments. They happen through doing the work. The people writing Nova, the people maintaining the abstractions, the people writing benchmarks to catch the hidden costs, even the people arguing against integration are all part of the same process. That process is messy. That process is productive. That process has 600,000 lines of code to show for itself.
What would you like to explore further? The technical details of how Rust abstractions hide behind the kernel’s C interface? The specific CVE categories that memory safety prevents? Or the economics of why Google committed to this transition when they did? I am interested in what questions the data raises for you.
