The Numbers Tell a Story That Wasn’t Obvious in 2022
When Rust support landed in Linux kernel 6.1 back in late 2022, the initial merge brought roughly 13,000 lines of code. It was significant enough to matter, but small enough that plenty of seasoned kernel developers could dismiss it as an experiment that might not survive the next hardware cycle. I remember the threads on LKML: respectful skepticism mixed with genuine concern about toolchain stability and the learning curve ahead. Fair questions, all of them.
Fast forward to early 2026, and the kernel now carries over 600,000 lines of Rust across drivers, filesystem abstractions, and core subsystem bindings. That’s not a rounding error. That’s a structural shift. The exponential growth rate tells you something important about adoption trajectories in infrastructure projects. They tend to either collapse or accelerate past the point where anyone can reasonably call them temporary.
What makes this particularly interesting is the diversity, not just the volume. We’re not talking about isolated experiments in a single subsystem. Rust abstractions now touch GPU drivers, storage stack interfaces, and network-adjacent code. The Nova GPU driver for NVIDIA’s open-source firmware became the highest-profile all-Rust driver effort to date, and Linus Torvalds explicitly confirmed in a December 2025 post that driver contributions have accelerated. That’s not hype. That’s a maintainer-level observation from someone whose opinion on this matters more than anyone else’s.
The Memory Safety Argument Stopped Being Philosophical
Here’s where this gets less abstract. A 2025 study from the University of Waterloo analyzed 150 Linux kernel CVEs from 2020 through 2024. They ran the numbers on what categories these vulnerabilities fell into. Sixty-seven percent of them were memory safety issues that Rust’s ownership model structurally prevents you from creating in the first place. Not “probably prevents.” Structurally prevents. The compiler won’t let you build it.
When you’re dealing with kernel code, a preventable category of vulnerability isn’t a nice-to-have feature. It’s a literal reduction in the attack surface that matters at scale. I’ve spent enough time tracing through buffer overflow exploits to know that the difference between a vulnerability class that exists and one that doesn’t is not subtle.
The real-world impact shows up even more clearly when you look at what Google’s Android team reported in 2025. Their proportion of new OS-level code written in memory-safe languages hit 77%, with Rust taking the majority of systems-level work. More importantly, memory safety vulnerabilities as a percentage of total Android CVEs dropped below 24% for the first time. That’s not correlation. That’s measurable outcome. You can read the details on the Google Security Blog on memory safety in Android and see exactly how they’re tracking this.
The thing that gets missed in these conversations is that this isn’t about Rust being perfect. It’s about Rust removing entire classes of problems from your problem space. When you’re operating at Android’s scale or the Linux kernel’s scale, removing a category of problems is genuinely worth reorganizing your toolchain around.
The Abstraction Tax Conversation Got Real
But here’s where the honest part of this story lives: not everyone is convinced the tradeoffs are worth it. In late 2025, Ted Ts’o, a veteran C maintainer who’s been shipping production kernel code longer than most of us have been writing code, posted a detailed technical critique on LKML. His argument was sharp and specific. Rust’s abstraction layers were creating hidden performance regressions in I/O paths. Not the kind you’d catch with synthetic benchmarks. The kind that show up when you’re pushing real sustained workloads.
This matters because it’s not someone arguing from principle. It’s someone with decades of shipping production systems pointing at concrete technical problems. When a person like that voices concern about abstraction costs in the kernel, you listen. And the kernel maintainers did. The conversation that followed was technical, thoughtful, and unresolved in the way that most honest technical disagreements are.
This is also the moment where I need to be direct: I don’t think Ts’o is wrong. I think he’s identified a real problem. Rust’s abstraction layers do add compilation-time complexity. They do sometimes create layers of indirection that C doesn’t have. The question isn’t whether these costs exist. It’s whether they’re worth paying given the vulnerability reduction you get in return. That’s not a technical question. That’s a business and risk question wearing a technical disguise.
The Mailing List Drama Is Actually a Feature
Here’s what I find myself explaining to people who are new to how kernel development actually works: the LKML arguments over Rust are not a sign that the project is broken. They’re a sign that it’s working correctly. The kernel has a culture of brutal technical honesty. Maintainers will tear into your patch if it’s wrong, and they’ll do it in public. That’s not hostile. That’s professional.
The Rust debates follow that pattern exactly. You’ve got people arguing passionately about memory safety benefits. You’ve got people worried about abstraction costs and compile times. You’ve got concerns about toolchain stability and what happens when the Rust ecosystem makes breaking changes. These are legitimate engineering discussions, and they’re supposed to happen in public where everyone can see the reasoning.
What you’re not seeing is Rust getting blocked out of the kernel because someone decided it was too risky. What you’re seeing is Rust getting integrated incrementally while the community figures out where it makes sense and where it doesn’t. GPU drivers? Yes. Core scheduler code? Not yet. That’s how infrastructure projects should work.
Where We Actually Are
If I’m being honest about where this stands in early 2026, Rust in the Linux kernel is past the point where the question is whether it survives. The question is how deep it goes. Can you write a high-performance filesystem in Rust that doesn’t trade throughput for safety? Can you build interrupt handlers that don’t add latency? These aren’t settled questions yet, and that’s okay. They’re the right questions to be asking.
The documentation exists now. You can read through the Linux kernel Rust documentation and see what abstractions the maintainers have landed on. There’s actual code you can study. There are real drivers shipping. This isn’t theoretical anymore.
The truth that doesn’t fit neatly into either the “Rust is the future” or “Rust is a distraction” camps is that both things are partially true. Rust genuinely does prevent entire categories of security vulnerabilities. Rust abstractions genuinely do add complexity in places where kernel developers have spent decades minimizing it. The kernel community’s approach of doing it anyway but carefully seems like the sane middle ground to me.
If you’ve been following this evolution or have your own stories about working with Rust in systems code, I’d genuinely like to hear what you’re seeing on the ground. The mailing list drama is useful signal, but real experience reports matter too. Drop a comment or reach out.
