Rust in the Linux kernel stopped being an experiment on April 12, 2026. 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 rather than tolerated. Rust code has shipped in Android drivers, file systems, and network components for a while — what changed is that it is now a supported way to contribute, with maintainer obligations attached.
The part most coverage misses: policy was never the real blocker, and removing the label does not remove the actual one. You still cannot write a Rust driver for a subsystem that has no safe Rust abstractions, and building those abstractions — not writing drivers — is where the work is.
This article covers what Linux 7.0 actually changed, what the coexistence policy means, why DRM is the subsystem to watch, and whether you should write your next driver in Rust.
Key Takeaways
- Linux 7.0, released April 12, 2026, removed the experimental label from Rust — the first release where Rust drivers are officially supported.
- The kernel's explicit policy is coexistence: Rust for new code, C for existing subsystems, and no forced migrations.
- The real constraint is subsystem bindings — you can only write a Rust driver where safe abstractions over the C APIs already exist.
- DRM is roughly a year from requiring Rust and disallowing C for new drivers, which would be the first subsystem to go Rust-only.
- Outside the kernel, Debian's APT took a hard Rust dependency in May 2026 — Rust is becoming unavoidable in the base system, not just optional.
What did Linux 7.0 actually change?
Linux 7.0 removed the EXPERIMENTAL designation from CONFIG_RUST. In practical terms, that converts Rust from something the kernel would accept but not promise anything about, into a supported language with the ordinary stability expectations attached.
The change had been building for months. In December 2025, Rust development became an official part of kernel development rather than a side project, which devclass reported as the decisive policy moment. Linux 7.0 was the release that made it visible in the config.
What "supported" concretely buys a contributor:
| Before Linux 7.0 | After Linux 7.0 |
|---|---|
| Rust support marked experimental | Rust support is a standard config option |
| Abstractions could break without notice | Ordinary kernel stability expectations apply |
| Rust drivers were case-by-case | Rust is an accepted way to write a new driver |
| Contributors had no maintainer guarantees | Rust abstractions have maintainers |
What it does not buy: any obligation on a C maintainer to accept, review, or accommodate Rust in their subsystem. That distinction is the entire practical story, and it is covered by policy rather than by the config flag.
What is the coexistence policy?
The kernel's explicit position is Rust for new code, C for existing subsystems, and no forced migrations. Nobody is rewriting the VFS. Nobody is being told to learn Rust to keep maintaining their driver.
This is deliberate and it is the reason the transition has not fractured the project. The alternative — mandating Rust anywhere — would have meant asking thousands of maintainers to either learn a new language or hand over code they have maintained for twenty years. That fight would have been unwinnable and the tension around it was real enough through 2025 to generate multiple public disputes.
Coexistence has a cost, and it should be named. Two languages in one kernel means two toolchains, two sets of build requirements, duplicated abstractions at every boundary, and a permanently larger surface for contributors to learn. Anyone claiming this is free is selling something. The bet is that memory safety in new code is worth that overhead.
The safety argument rests on a well-known pattern: a large majority of kernel CVEs historically stem from memory-safety errors — use-after-free, buffer overflow, and similar — which Rust's ownership model eliminates as a class in safe code. Estimates that Rust could remove roughly 80% of Linux kernel CVEs circulate widely; treat the exact figure as an approximation of the memory-safety share rather than a measured outcome, since Rust only helps in code that is actually written in Rust.
What does a Rust kernel driver look like?
Close enough to idiomatic Rust that the ownership model does real work, and far enough from userspace Rust that you cannot bring your crates. Here is the shape of a minimal module:
use kernel::prelude::*;
module! {
type: MinimalDriver,
name: "minimal_driver",
author: "Your Name",
description: "A minimal example driver",
license: "GPL",
}
struct MinimalDriver {
buffer: KVec<u8>,
}
impl kernel::Module for MinimalDriver {
fn init(_module: &'static ThisModule) -> Result<Self> {
pr_info!("minimal_driver: loading\n");
// Allocation is fallible in the kernel: no silent OOM abort.
let mut buffer = KVec::new();
buffer.push(0u8, GFP_KERNEL)?;
Ok(MinimalDriver { buffer })
}
}
impl Drop for MinimalDriver {
fn drop(&mut self) {
pr_info!("minimal_driver: unloading, {} bytes\n", self.buffer.len());
}
}
Two details carry the argument. Allocation is fallible — push takes a GFP flag and returns a Result, because a kernel cannot abort on out-of-memory the way a userspace program can. And Drop runs the cleanup path automatically, which is precisely the class of bug that produces use-after-free CVEs when a C error path forgets a kfree.
What you give up is the ecosystem. No std, no async runtime, no crates.io. Kernel Rust is Rust the language with the kernel's own library, and that is a meaningfully smaller thing to work with than the Rust most developers know.
Can I write my next driver in Rust?
Only if your subsystem already has safe Rust abstractions over its C interfaces. This is the constraint that actually determines whether Rust is available to you, and it is invisible in most coverage of the stability milestone.
Here is why. The kernel's C APIs are not directly callable from safe Rust — someone has to write a binding layer that wraps the raw C calls in types enforcing the correct lifetime, locking, and error semantics. Until that layer exists for your subsystem, "Rust is supported" is true and irrelevant to you.
So the practical decision path is:
- Check whether your subsystem has abstractions. Some do. Many do not. This is the actual gate.
- Check who maintains them. Abstractions with an active maintainer are usable; orphaned ones are a liability.
- Assess your team. Kernel Rust is a distinct dialect. Existing Rust experience helps; it is not sufficient.
- Confirm the maintainer will take it. No C maintainer is obligated to accept Rust in their subsystem, and some will not.
If the abstractions exist and the maintainer is willing, Rust is a good choice for new driver work today. If they do not, the highest-value contribution is writing the abstractions — which is harder, slower, and far more useful to everyone who comes after you.
Why DRM is the subsystem to watch
The Direct Rendering Manager — the graphics subsystem — is reportedly about a year from requiring Rust and disallowing C for new drivers. That would make it the first kernel subsystem to go Rust-only for new code, and it is the leading indicator worth tracking.
The choice makes sense on the merits. Graphics drivers are large, complex, full of lifetime and concurrency hazards, and historically a rich source of memory-safety bugs. They are also comparatively self-contained, so a Rust-only policy there does not cascade through the rest of the kernel.
If DRM completes that transition without a maintainer revolt or a stalled driver pipeline, expect other subsystems to follow. If it stalls, the coexistence model stays permanent — which is a perfectly good outcome, just a different one.
Rust is spreading past the kernel too
The kernel is the headline, but the more consequential shift for most developers happened in userspace. In May 2026, Debian's package manager took a hard Rust dependency: the Rust compiler, standard library, and parts of the Sequoia PGP ecosystem are now integrated into APT's core.
That is a different kind of milestone. A kernel config option is opt-in. A Rust dependency in APT means every Debian and Debian-derived system requires a working Rust toolchain to build its package manager — Rust is now part of the base system on a large fraction of the world's servers, whether or not anyone opted into it.
The same pattern is visible across developer tooling, where Rust rewrites have become the default answer to "this is too slow." We covered the JavaScript toolchain shift in Biome vs ESLint and Prettier, and the Python side in uv vs Poetry vs pip — a story that got a great deal more interesting when OpenAI acquired Astral, the company behind uv and Ruff.
Frequently asked questions
Is Rust officially supported in the Linux kernel? Yes. Linux 7.0, released April 12, 2026, removed the experimental label from Rust support, making it the first kernel release where writing a driver in Rust is officially supported. Rust became an official part of kernel development in December 2025.
Is the Linux kernel being rewritten in Rust? No, and there is no plan to. The kernel's explicit policy is coexistence: Rust for new code, C for existing subsystems, and no forced migrations. Existing C subsystems stay in C and their maintainers are under no obligation to change.
Can I write any Linux driver in Rust now? Only where safe Rust abstractions over that subsystem's C APIs already exist. Official support does not automatically create bindings, and without them a Rust driver for that subsystem cannot be written safely. Checking for existing abstractions is the first step, not checking the kernel version.
Does Rust eliminate Linux kernel CVEs? It eliminates memory-safety bugs as a class in safe Rust code, which historically account for a large majority of kernel CVEs. Estimates around 80% circulate widely, but the benefit only applies to code actually written in Rust — the existing C codebase is unaffected.
Can I use crates.io libraries in kernel Rust?
No. Kernel Rust has no std, no async runtime, and no access to the general crate ecosystem. It uses the kernel's own library with fallible allocation and kernel-specific types, so it is a distinct dialect rather than the Rust most developers write in userspace.
Which Linux subsystem will require Rust first? DRM, the graphics subsystem, is reportedly about a year from requiring Rust and disallowing C for new drivers. That would make it the first subsystem to go Rust-only for new code, and its success or failure is the best available signal for whether other subsystems follow.
The verdict
Removing the experimental label was the right call and a smaller event than it reads. Rust was already shipping in Android drivers and file systems; Linux 7.0 formalized a reality rather than creating one.
If you are deciding what to write next: check for abstractions in your subsystem first, talk to the maintainer second, and pick a language third. That ordering will save you more time than any argument about memory safety. And if the abstractions do not exist, writing them is the most valuable thing you can contribute — it is the actual bottleneck, and it is where the transition either succeeds or stalls.
Watch DRM. Everything else is commentary until a subsystem says C is no longer accepted and the drivers keep coming anyway.
