By Two milestones landed within weeks of each other. In April, Linux 7.0 formally removed the “experimental” label from Rust support — making it the first kernel release where writing a driver in Rust is officially supported, not quietly tolerated. Then in May 2026, Debian’s APT package manager added a hard Rust dependency, pulling the language into the package infrastructure that underpins every Ubuntu, Mint, Kali, and Raspberry Pi OS machine on the planet. Between those two events, Rust crossed a line: it stopped being a bet on the future of systems programming and became load-bearing infrastructure.
What “Stable” Actually Means in Linux 7.0
This isn’t just a label change. When the Linux kernel calls something “experimental,” it means maintainers can refuse patches, tooling isn’t guaranteed, and nobody should be deploying it in production. Removing that label — as happened in Linux 7.0 released April 12, 2026 — means new kernel subsystems can now formally accept Rust drivers, and the bar for Rust patches is the same as for C.
The decision came out of the December 2025 Linux Kernel Maintainers Summit in Tokyo. Greg Kroah-Hartman, who reviews nearly every kernel driver patch submitted, put it plainly: “Drivers in Rust are proving to be far safer than those written in C.” Rust-for-Linux maintainer Miguel Ojeda was more direct: “The experiment is done, i.e. Rust is here to stay.”
The practical signal is the driver core changes in 7.0. The Rust kernel API now exposes the foundational building blocks that driver development actually requires: PCI device enumeration, interrupt handling, DMA mapping, and platform device registration. You no longer need to drop into C to interface with bus hardware.
What You Can Build Now
Theory aside, here’s what has actually shipped. In Linux 7.0, Rust-based drivers for NVMe storage and high-speed networking moved from experimental branches into the mainline stable tree. The Rust NVMe driver shows a 10% reduction in latency during high IOPS workloads compared to the legacy C driver — a result of the ownership model eliminating traditional locking overhead. A Rust driver isn’t just safer; in this case it’s faster.
The production deployment story is already larger than most people realize. Android 16, built on kernel 6.12, shipped Google’s ashmem anonymous shared memory subsystem rewritten in Rust. That code runs on hundreds of millions of Android devices. This is not a staging environment.
The module loader has also been revamped. It now handles Rust-specific initialization automatically, which eliminates the boilerplate scaffolding that plagued early Rust kernel development. A minimal driver now looks like this:
use kernel::prelude::*;
module! {
type: MyDriver,
name: "my_driver",
author: "Your Name",
description: "A safe Rust kernel driver",
license: "GPL",
}
struct MyDriver;
impl kernel::Module for MyDriver {
fn init(_module: &'static ThisModule) -> Result<Self> {
pr_info!("MyDriver loaded
");
Ok(MyDriver)
}
}That’s a complete, loadable kernel module. The official quick start documentation will get you from zero to a compiled module in under an hour.
The Security Argument Is Now Empirical
The case for Rust in the kernel has always been the CVE argument: roughly 60–70% of kernel security vulnerabilities are memory safety bugs — use-after-free, buffer overflows, null pointer dereferences. Safe Rust makes these structurally impossible. The compiler enforces ownership, lifetime, and borrowing rules that prevent these classes of errors at compile time, not at runtime after a user has been exploited.
Skeptics pointed to CVE-2025-68260, the first Rust kernel CVE, a race condition in the Android Binder rewrite. But look at where the bug was: it lived inside an unsafe {} block. That’s the one place in Rust where you explicitly tell the compiler “I know what I’m doing, trust me” — the same position every C developer is always in. The CVE didn’t disprove safe Rust’s guarantees; it validated them. Safe code held. Unsafe code failed, just like C code can. Google has reported zero memory safety bugs in production from deployed Rust Android kernel code.
Debian APT: The Other Shoe Drops
The second milestone is quieter but arguably more significant for most developers. APT maintainer Julian Klode announced that Debian’s package manager would begin requiring a hard Rust dependency starting May 2026. The Rust compiler, standard library, and parts of the Sequoia PGP ecosystem are now integrated into APT’s core — initially targeting .deb, .ar, and .tar parsing, plus HTTP signature verification.
APT is the package manager for Debian and every distro derived from it: Ubuntu, Linux Mint, Pop!_OS, Kali Linux, Raspberry Pi OS, and more. When APT requires Rust, Rust becomes mandatory infrastructure on a substantial fraction of all Linux machines in the world.
For mainstream architectures (x86-64, ARM, RISC-V), this change is transparent — Rust toolchain support already exists. The impact is real for legacy ports: Alpha, HP PA-RISC (hppa), M68k, and SH4 have six months to provide a working Rust toolchain, or Debian will discontinue support for those platforms.
The Honest Catches
The enthusiasm is warranted, but three things are still genuinely hard.
The learning curve is steep. Writing a kernel driver requires understanding both Rust’s ownership model and Linux kernel internals — memory models, interrupt contexts, locking hierarchies, concurrency primitives specific to the kernel. These are separate bodies of knowledge and the intersection is a small community right now, though it’s growing fast.
The documentation gap is real. Linux 7.0’s driver core Rust documentation has improved substantially but still lags decades of C documentation, books, and examples. You will hit situations where the C path is well-documented and the Rust path requires reading source code.
And unsafe Rust is not magic. CVE-2025-68260 exists. If you’re writing a Rust driver that needs unsafe blocks, you’re taking on the same responsibility as C. The discipline is: minimize the unsafe surface, document every invariant, and treat unsafe blocks as the exception, not the pattern.
What to Do Next
If you write kernel code, or plan to, the path is straightforward: start with the kernel Rust quick start, read the existing drivers in drivers/, and set up a test VM. The module loader is good enough now that the workflow is no longer painful. If you maintain Debian-based infrastructure, nothing changes today for most systems — but Rust is now a build requirement to account for in locked-down or air-gapped environments.
Rust in the Linux kernel spent years proving it belonged. It’s done proving. The question now is what you build with it.
