Rust Just Went Stable in the Linux Kernel

Linux 7.0 was shipped in April 2026. It is evident that Rust stopped being an experiment in it and became a permanent official part of the kernel. This article covers what's actually changed, why it matters, and what's still true about the parts that didn't change.

A quick refresher on what the kernel does

The kernel is the core program responsible for running the operating system. It allows direct communication of software with the hardware of the system, be it memory, disk, network card, or any other component. Linux's kernel has been written almost entirely in C since 1991.

The reason the kernel was written in C is that it is a low level programming language and provides better control over hardware, which is essential in kernel development. C gives full control over memory, it can be decided exactly when the memory gets allocated and freed. However, the control introduces major problems as well. Freeing memory too early, forgetting to free it, writing one byte past the end of a buffer, the program might not crash right away, but it silently corrupts something, which becomes a security hole months later.

Three kinds of bugs cause most of the damage here:

• Use-after-free: using memory after it's already freed.
• Buffer overflow: writing past the space given.
• Null pointer dereference: reaching for something that was never there.

Why this actually matters

Rust does the tracking of memory ownership at compile time, instead of doing it during runtime. It is ensured that every piece of memory has exactly one owner, and this is checked by the compiler before the code even gets to run. If an attempt is made to use memory after it's freed, or from two places unsafely at once, Rust simply refuses to compile, and this is achieved without a garbage collector or any added cost while the program runs.

The practical difference lies in when a bug gets caught, illustrated in Figure 1. In the case of C, a memory bug typically gets compiled without issues, gets shipped, and only shows up once it is already running on someone's machine, sometimes as a crash, sometimes as a security hole that is discovered much later. In the case of Rust, the same category of bug stops the build before it ever leaves the developer's machine.

The scale of the problem

This is not a theoretical concern. It is found that roughly two-thirds of all Linux kernel CVEs (publicly tracked security vulnerabilities) can be traced back to exactly the three bug types mentioned above, as shown in Figure 2.

This is the number that actually drove this decision. It is not a language preference that is being talked about here; it is a security one.

What's actually written in Rust right now

It is made mandatory as of 7.0 that kernel builds require a stable Rust compiler, version 1.93 or newer. The real code that is sitting on top of it includes:

• Nova, the new open-source NVIDIA GPU driver, is written in Rust from the ground up. It is split into two pieces, Nova-Core handles the low-level hardware and firmware communication, and Nova-DRM is the graphics driver that is seen by userspace. Most of this work is being driven by Red Hat.
• Android's Binder driver, which is the mechanism used by apps to communicate with each other and with system services, has been given a Rust rewrite that is now shipping on real devices.
• The NVMe storage driver has a Rust implementation under active development. NVMe is the standard used by modern solid-state drives, the storage chip inside most laptops and servers today. In tests where the drive is hit with a very high number of read and write requests every second, the kind of load a busy server sees, the Rust version measured 10% faster than the C driver. That's because Rust's ownership model can safely skip some of the locking C needs to prevent two operations from colliding.

Below all of this sits a layer of shared plumbing that every new Rust driver can reuse instead of rebuilding from scratch. In plain terms, it covers three things: how the kernel talks to expansion hardware like graphics cards and network cards, a standard called PCI (Peripheral Component Interconnect); how it flips the simple on/off electrical switches used to control physical components on a circuit board, called GPIO (General Purpose Input/Output); and how a device is allowed to move data directly in and out of memory without asking the processor to copy every byte by hand, called DMA (Direct Memory Access). The names aren't important to remember, what matters is that these are basic building blocks nearly every driver needs, and now that they exist in Rust, each new Rust driver gets to reuse them instead of rebuilding them from scratch.

Figure 3 lays out how all of this stacks together, and the key thing to notice is that not every layer behaves the same way. The top row, Nova, Binder, and NVMe, is written fresh for each driver, that's new code every time, specific to whatever piece of hardware it's talking to. The layer just below it, the PCI, GPIO, and DMA support code, is the opposite: it's written once and reused by every driver that comes after it, so nobody has to rebuild that plumbing from scratch again. And at the very bottom sits the C core, which isn't reused so much as simply left untouched, the scheduler, memory management, and everything else that has been running Linux for over three decades, still written in C and not going anywhere, which is exactly the question the next section answers.

Does C go away?

No. It should not be assumed that the kernel is being rewritten; there is no timeline where that happens.

The agreement that was made with the maintainers, who were initially skeptical of Rust, was kept specific. It was agreed that new code, especially new drivers, can be written in Rust starting now. It is not the case that existing C subsystems are being rewritten just because a safer option exists. The core of the kernel, the scheduling, the memory management, the parts that have been battle-tested for three decades, remains C for the foreseeable future.

It can be said that Rust is being added here, and is not replacing anything.

One honest caveat

Rust's first kernel CVE was received in December. It was a race condition found in the Android Binder driver, living inside an unsafe block, which is the one place in Rust where the safety checks are switched off on purpose and the compiler is told to "trust me."

It should not be considered that Rust failed here. It is seen that the checks which were switched on did their job everywhere, except for the one place where a person switched them off.