Rust Goes Stable in Linux Kernel 7.0: What It Means for Developers

Linux 7.0 makes Rust a permanent part of the kernel development model. Kernel builds now use stable Rust releases anchored to the Debian stable toolchain. Drivers like NVIDIA’s Nova and Android’s ashmem already run on millions of devices. This policy change lets developers use a language that eliminates memory-safety bugs at compile time.

Why the Kernel Needed Rust in the First Place

Bringing Rust into the kernel wasn’t about ideology. About two-thirds of kernel security bugs come from memory issues like buffer overflows and use-after-free errors. These are the expected costs of writing software in C. Manual memory management gives control but lacks guardrails. One mistake can lead to a major exploit or a system crash.

C’s memory model made sense in 1972. The kernel was small then, and hardware was simple. Today the kernel has tens of millions of lines of code. It runs on everything from small sensors to huge data centers. The risk of bugs has grown, but manual memory management is still as hard as ever.

Rust solves these problems at the language level. Its ownership model tracks object lifetimes while the code compiles. This means there’s no garbage collector to slow things down. The borrow checker stops bugs before the code even runs. Safe Rust code prevents the errors that cause most kernel security issues.

The promise to kernel maintainers was clear. Rust won’t replace C in existing parts of the kernel. It’s for new code and drivers where safety can be built in from day one. There won’t be any forced rewrites or migrations.

The Journey from 6.1 to 7.0

Rust’s move into the mainline kernel took four years. It caused real debate along the way.

The first milestone was Linux 6.1 in late 2022. This version added basic Rust support and build tools. You couldn’t write a full driver yet, but the foundation was there.

Linux 6.8 in 2024 moved from tools to real work. The first Rust drivers entered the tree. They proved the language could handle kernel needs like memory and concurrency. It wasn’t just a toy anymore.

Android gave the biggest proof of scale. Android 16 used a Rust version of the ashmem system. This put Rust kernel code on millions of devices for daily use.

The turning point was the 2025 Maintainers Summit. After years of debate, maintainers agreed that Rust stays. The policy is clear: Rust is for new code, and C stays for old code. No one is forced to migrate.

Linux 7.0 in 2026 finally removed the experimental tag from Rust. Four years after the first merge, the experiment is done.

What “Stable” Actually Means Technically

When kernel developers say “stable Rust,” it means more than just a release channel.

Before 7.0, you needed a nightly compiler to build a Rust-enabled kernel. Nightly builds use features that aren’t finished yet. This caused problems because builds could break if the Rust project changed an API. Distributors were nervous about these risks.

Linux 7.0 removes that need. The kernel now builds with the stable Rust track. Rust 1.93 is the minimum version. This is the same tool other Rust developers use.

Debian’s anchor policy handles distribution support. The kernel project supports the Rust version in the current Debian stable release . Debian sets the standard for many distros. This policy gives maintainers a clear baseline. It stops developers from needing a newer compiler than what their distro provides.

Linux 7.0 adds new driver tools. They let Rust drivers do more without using unsafe code:

• dev_printk support for all Rust device types. This connects Rust drivers to standard kernel logs.
• dma_set_max_seg_size() for Rust DMA drivers. This helps storage and network drivers manage memory better.
• Generic I/O tools for register access. This covers how drivers talk to hardware.
• A sample SoC driver that serves as an official template for new developers.

That last item is very important. New developers often struggle without clear examples. The SoC template gives reviewers a standard to follow. It shows what good Rust kernel code should look like.

Real Rust Drivers Already Shipping

Rust kernel code is already used at a large scale.

Google’s Android ashmem system runs on every Android 16 device. Sharing memory between processes is a key feature. It’s used all the time. Rust kernel code has handled this on millions of phones without any problems.

NVIDIA’s Nova GPU driver is a complex project. Nova is a full DRM driver for older RTX and GTX GPUs. It’s split into two parts. nova-core talks to the hardware. nova-drm works with the Linux graphics API. GPU drivers are very hard to write. They handle firmware and display tasks. Having Nova in the kernel shows that maintainers now trust Rust.

The Arm Mali Tyr driver is also moving forward. It brings Rust to the graphics chips in many mobile devices. This includes phones, tablets, and laptops.

The sample SoC driver in 7.0 is a great tool for new developers. It’s a reviewed example you can study. Most kernel parts have these reference models. This one sets a standard for Rust drivers. It makes it easier for new people to contribute.

The Controversy: A Culture Clash in the Kernel Community

The transition was contentious, and the record is worth being accurate about.

The sharpest public conflict came in February 2025 over a Rust binding for the kernel’s C-based DMA API. Christoph Hellwig, a longtime kernel maintainer responsible for much of the storage and DMA infrastructure, clashed with Hector Martin of Asahi Linux over the approach. The technical disagreement was about how Rust abstractions should wrap existing C APIs, but it carried a harder question underneath: does Rust’s presence in the kernel impose new maintenance burdens on C subsystem owners who never asked for it?

Linus Torvalds stepped in publicly. His message defended the technical validity of the Rust patch while making clear that no individual maintainer’s preferences would override kernel-wide policy. The intervention did not resolve the cultural tension, but it established where authority sits on these questions.

The formal policy is explicit: Rust code will not be forced into any subsystem over a maintainer’s objections. Subsystem owners can actively accept Rust contributions, remain hands-off, or decline them. The model is coexistence, not displacement.

The controversy picked up a new thread when the first CVE traced to a Rust unsafe block was reported. Rust’s safety guarantees apply only to safe code. The unsafe keyword exists for situations where the programmer must take direct responsibility for memory correctness - unavoidable when interfacing with hardware or calling into C APIs. That CVE did not undermine the case for Rust in the kernel, but it reminded everyone that unsafe blocks require the same rigorous review as equivalent C code, and that the kernel’s Rust abstractions are not automatically safe just because they are written in Rust.

Both sides have had to adjust. Rust advocates had to accept that coexistence means respecting C maintainers’ authority over their subsystems. C veterans had to accept that the kernel’s long-term direction now includes a second systems language, and that it is not going anywhere.

What This Means for Kernel Developers

The 7.0 milestone has concrete implications for anyone who writes kernel code or wants to start.

The skill expectations are shifting. For new kernel contributors, proficiency in both C and Rust is becoming the baseline. C remains essential because the overwhelming majority of existing kernel code is C and will stay that way for a long time. But reviewers increasingly expect new driver submissions to at least consider whether Rust is the appropriate choice, and knowing only one language limits where a developer can contribute effectively.

The most practical entry point is what some developers call the “leaf driver” approach. Rust is poorly suited for deep kernel infrastructure - the scheduler, the memory allocator, the VFS layer all have decades of C code, tight inter-subsystem dependencies, and maintainers with good reasons to be conservative. At the edges, the case is clearer: networking drivers, storage controllers, NVMe, GPU drivers. These are more self-contained, interact with the rest of the kernel through defined interfaces, and are precisely where use-after-free and buffer overflow bugs in C have historically done the most damage.

On tooling: Cargo has been adapted for no-std kernel crates, since kernel code cannot use the Rust standard library. CI pipelines now test Rust builds alongside C. rust-analyzer integration with kernel source trees is functional but not yet as smooth as in a regular Rust project; developers accustomed to the IDE experience in application development will find it rougher than expected. For managing pinned Rust toolchain versions across projects, Nix shells offer a reproducible alternative to system-wide installations.

The empirical data from Android is relevant. Google’s published results suggest that Rust components introduce significantly fewer memory-safety bugs than equivalent C code. The kernel environment is not the same as Android userspace, but ownership, borrowing, and compile-time lifetime analysis work the same way in both. Those numbers are the clearest evidence available that the kernel’s bet on Rust is likely to produce measurable security improvements over the next several kernel release cycles.

The transition will take years. Existing C drivers are not going to be rewritten, and the kernel’s overall character will remain C-dominant for the foreseeable future. But new drivers written in Rust starting now will still be running in production a decade from now, carrying none of the memory-safety bugs they were never allowed to introduce.