Rust in the Linux kernel: the experiment is over, Rust is here to stay

The Linux kernel carries more than three decades of C, runs on billions of devices, and most of its serious vulnerabilities still fall into familiar classes: buffer overflows, use-after-free, data races. In 2022 Rust entered the kernel as an "experiment". In December 2025, at the Kernel Maintainers Summit in Tokyo, that experiment was declared over. Miguel Ojeda, who leads Rust for Linux, wrote: "the experiment is done, i.e. Rust is here to stay". This article explains how Rust is wired into the kernel, where it already runs, and what the kernel's first Rust CVE teaches us.

Architecture: bindings, abstractions and drivers

Rust in the kernel does not rewrite the C core. According to the kernel's own documentation, it is organised in three layers:

That last rule is the key. If the abstractions are sound and every unsafe block honours its safety contract, driver code built on those abstractions cannot introduce undefined behaviour. The dangerous part is concentrated in a small, heavily reviewed place instead of being spread across thousands of drivers.

Where Rust already runs

• Android 16: devices on kernel 6.12 ship the ashmem shared-memory allocator written in Rust, so millions of phones already run Rust kernel code.
• Binder rewritten in Rust: merged in 6.18, living side by side with the old C version so vendors can choose.
• Graphics drivers: per DevClass, DRM maintainer Dave Airlie said DRM is about a year away from requiring Rust for new drivers.
• Greg Kroah-Hartman observed that Rust drivers are proving safer than C ones, and that Rust–C interaction problems have been fewer than expected.

The kernel's first Rust vulnerability: CVE-2025-68260

Shortly after Rust Binder landed, a CVE was assigned to that very driver. It is a race condition in how the death_list is managed: in Node::release, the code takes a lock, moves items to a local list, then drops the lock. An unsafe block assumed an item would never sit in another node's list, and that assumption broke under concurrency. The result was memory corruption and kernel crashes. It is locally exploitable only, was introduced in 6.18 and fixed in 6.18.1 and 6.19-rc1.

The lesson is not "Rust isn't safe either". The lesson is that the bug sat exactly where the design predicted: inside an unsafe block, where the programmer is responsible for proving safety. Investigators knew precisely where to look.

Remaining risks and limits

• Not every configuration is supported: Ojeda was explicit that ending the experiment does not mean every architecture, configuration or toolchain works. Rust code is not built by default yet.
• Toolchains: gccrs (Rust on GCC) is not complete. Less common architectures such as s390 could suffer if Rust became mandatory.
• unsafe stays a hotspot: as the CVE shows, races and wrong assumptions inside unsafe still corrupt memory.
• Human cost: maintainers need to read both C and Rust, and abstractions must keep up with C API changes.

How to apply it

• Dev: If you write drivers or systems code, learn the "bindings → abstractions → safe code" pattern. It transfers directly to your own C/C++ projects: one thin layer holds all the unsafe, everything else stays safe.
• Tech Lead: Adopt the kernel's rule: business modules never call FFI directly; every unsafe block carries a SAFETY: comment explaining the invariant and gets a dedicated review, especially around locks and threads.
• PM: The world's largest infrastructure project now treats Rust as permanent. That is a hiring and training signal: systems Rust skills are becoming a requirement, not an experiment.