Linux kernel 6.11 was released this past Sunday, and while every kernel release brings a grab bag of driver updates, performance tweaks, and architecture improvements, this one continues a trend that I find particularly fascinating: the steady expansion of Rust code in the kernel.
It’s been two years since Rust initially landed in Linux 6.1, and what started as a cautious experiment — limited infrastructure, basic abstractions — is now growing into something that looks increasingly permanent and significant.
The State of Rust in 6.11#
The 6.11 release expands Rust’s footprint in several ways. There are new abstractions for kernel data structures, improved bindings for device driver development, and continued work on the tooling that makes it possible to write kernel modules in Rust that interoperate cleanly with the existing C codebase.
Perhaps more importantly, the pace of Rust-related patches has accelerated. The kernel mailing list now regularly includes Rust-related submissions, and the review process — while still rigorous — has become more routine. The initial friction of “should we even be doing this?” has largely given way to “how do we do this well?”
This matters because the Linux kernel is arguably the most conservative large-scale codebase in the world. Linus Torvalds doesn’t accept changes lightly, and the maintainer community has decades of deeply ingrained C practices. The fact that Rust is not only surviving but expanding in this environment says something important about the language’s maturity and its value proposition for systems programming.
Why Rust in the Kernel Matters#
The case for Rust in the kernel has always been about memory safety. The Linux kernel has historically been plagued by classes of bugs — use-after-free, buffer overflows, null pointer dereferences — that are largely eliminated by Rust’s ownership model. A study by Google’s Android team found that memory safety bugs accounted for roughly 65% of security vulnerabilities in their codebase, and the kernel is no exception.
But the value goes beyond just preventing crashes. Memory safety bugs in the kernel are security vulnerabilities. Every use-after-free in a kernel driver is a potential privilege escalation exploit. By writing new drivers and subsystems in Rust, the kernel community can systematically reduce the attack surface of the most critical piece of software on most computing devices.
The counterarguments are real, though. Rust introduces build complexity — you now need a Rust compiler in your kernel build toolchain. The language’s learning curve is steep, particularly for developers who’ve spent decades in C. And the interoperability layer between Rust and C code isn’t free — there’s cognitive overhead in maintaining clean boundaries between the two.
I’ve heard veteran kernel developers express frustration about this, and I understand it. If you’ve been writing C kernel code for twenty years, being told that a new language will make your code safer can feel dismissive of the enormous skill and discipline that’s gone into keeping the kernel as stable as it is.
The Broader Systems Programming Shift#
What’s happening in the Linux kernel reflects a broader shift across systems programming. The White House’s ONCD (Office of the National Cyber Director) published a report earlier this year explicitly recommending that organizations move toward memory-safe languages for critical infrastructure. CISA has been saying similar things. When government agencies start making language recommendations, you know the conversation has moved beyond academic debate.
In my own work, I’ve been watching teams adopt Rust for infrastructure tooling — CLI tools, network proxies, embedded systems — and the pattern is remarkably consistent. The initial learning curve is painful, the first few months are slow, and then productivity catches up and the class of bugs that used to consume debugging time simply stops appearing.
It’s reminiscent of the gradual adoption of type systems in the JavaScript ecosystem. TypeScript faced similar resistance (“JavaScript is fine if you’re disciplined enough”), and now it’s effectively the default for serious web development. Rust may follow a similar trajectory for systems work, though the timeline will be longer because the stakes are higher and the existing codebases are larger.
What 6.11 Means Practically#
For most Linux users and even most developers, 6.11 is a routine kernel update. You’ll get it through your distribution’s package manager in due course, and you probably won’t notice anything different.
For those of us who care about the long-term health of the software ecosystem, though, this release is another data point in an important trend. The kernel — the most critical, most conservative, most scrutinized codebase in open source — is betting on Rust. Not replacing C wholesale, not rewriting everything from scratch, but systematically using a memory-safe language for new development where it makes sense.
That’s pragmatic engineering, and it’s exactly how these transitions should happen.
My Take#
I’ve written C professionally for most of my career, and I have deep respect for what the language enables. But I also have deep respect for evidence, and the evidence is clear: memory safety bugs are the dominant class of security vulnerabilities in systems code, and languages like Rust eliminate them by construction.
The Linux kernel’s gradual adoption of Rust isn’t a rejection of C — it’s an acknowledgment that we can do better for new code without throwing away the enormous investment in existing code. That’s the right approach, and I’m glad to see it gaining momentum with each kernel release.
If you’re a systems programmer who hasn’t tried Rust yet, 6.11 is as good an excuse as any to take a serious look. The language has matured substantially, the tooling is excellent, and the community is welcoming. You might be frustrated for the first few weeks, but I suspect you’ll be grateful after the first few months.
This post is part of my Developer Landscape series, tracking shifts in the broader software development ecosystem.