Will Rust Replace C in the Linux Kernel?

Will Rust Replace C in the Linux Kernel?

A Turning Point Has Arrived — But ‘Replace’ Is the Wrong Word

March 2026 | Analysis & Commentary

The Language That Built the World’s Most Important OS

Since Linus Torvalds created Linux in 1991, the kernel has been written almost entirely in C. This choice was natural: C offered direct hardware access, portability across architectures, and the kind of fine-grained memory control essential for a high-performance operating system. Over the decades, millions of lines of C code have made Linux the backbone of the internet, cloud infrastructure, Android smartphones, and supercomputers. In short, C and Linux grew up together.

But C’s greatest strength is also its most dangerous flaw. It hands developers total control over memory — and that freedom has a cost. Buffer overflows, use-after-free errors, null pointer dereferences, and data races have plagued low-level software for decades. A 2019 presentation by researchers Alex Gaynor and Geoffrey Thomas at the Linux Security Summit delivered a striking verdict: approximately two-thirds of all Linux kernel vulnerabilities stemmed from memory safety issues. The implication was clear — the language itself was part of the problem.

Enter Rust: Designed to Make Memory Errors Impossible

Rust, first released by Mozilla in 2015, was built with a single core promise: memory safety without a garbage collector. Through a strict ownership and borrowing model enforced at compile time, Rust makes entire classes of bugs — the very bugs responsible for most Linux kernel CVEs — impossible to introduce without explicitly opting out of safety guarantees using the language’s unsafe keyword.

The case for bringing Rust into Linux was compelling. Google demonstrated this in Android: as the proportion of new code written in Rust increased and the amount of new memory-unsafe C and C++ decreased, memory safety vulnerabilities dropped from 76% of total Android vulnerabilities in 2019 to 35% by 2022. For an operating system kernel used by billions of devices, the security implications were enormous.

Five Years of Fierce Debate

The journey from idea to acceptance was anything but smooth. When the Rust for Linux project was formally proposed around 2020, it triggered years of heated debate in the kernel community. Some veteran developers called the memory safety arguments an “insult” to the decades of careful work that had gone into hardening the kernel’s C code. Others raised practical concerns: Rust introduces a second compiler toolchain, different debugging workflows, and interoperability challenges at the boundary between Rust and C code.

Real disputes emerged. A notable conflict arose over how to implement Rust abstractions for the kernel’s Direct Memory Access (DMA) API. Senior kernel developer Ted T’so observed that maintainers simply do not have unlimited time, and they resist anything that increases their maintenance burden. The resistance was real, substantive, and sometimes personal.

Despite the friction, adoption moved steadily forward. Rust support was merged into the mainline kernel with Linux 6.1 in late 2022, marking the first time in Linux history that a second language was officially supported for kernel development. The first Rust-written drivers appeared in Linux 6.8 in 2024, including early work on GPU drivers for NVIDIA (the Nova project), Apple Silicon (Asahi Linux), and ARM Mali (the Tyr driver).

December 2025: The Experiment Is Officially Over

The pivotal moment came at the Linux Kernel Maintainers Summit in Tokyo in December 2025 — an invitation-only gathering of the kernel’s most senior developers. The consensus reached there was unambiguous. As Jonathan Corbet, a longtime Linux kernel developer and journalist, summarized it: Rust in the kernel is no longer experimental. It is now a core part of the kernel and is here to stay, and the “experimental” tag is coming off.

Kernel maintainer Steven Rostedt reported there was “zero pushback” at the summit. Miguel Ojeda, who leads the Rust for Linux project, released a formal patch confirming the shift: the experiment was done. Linus Torvalds had already signaled this direction at the Linux Foundation Open Source Summit in Korea in 2025, saying that Rust was “truly becoming part of the kernel” and was “no longer just an experimental thing.”

The decision carried practical weight beyond symbolism. Ojeda revealed at the summit that Android 16 devices — built on Linux kernel 6.12 — ship with the ashmem (anonymous shared memory subsystem) memory allocator rewritten entirely in Rust. Millions of consumer devices around the world are already running production Rust code in their kernels.

How Much Rust Is Actually in the Kernel?

The honest answer is: not much yet — but growing. By April 2025, the Linux kernel contained approximately 34 million lines of C code alongside just 25,000 lines of Rust. That is less than 0.1% of total kernel code. Rust’s footprint is real, but it remains a tiny fraction of an enormous codebase.

The strategy was never to rewrite Linux in Rust. From the beginning, the plan was selective adoption — targeting areas where Rust’s advantages are most valuable without destabilising mature, battle-tested C code. The primary focus has been on new device drivers, particularly “leaf” drivers for networking, storage, NVMe, and similar hardware, where Rust bindings can safely wrap existing kernel C APIs.

A telling signal of where things are heading: Dave Airlie, maintainer for the Direct Rendering Manager (DRM) graphics subsystem, announced at the Tokyo summit that the DRM project was approximately one year away from requiring Rust for all new drivers and disallowing C for new contributions to that subsystem.

The First Rust CVE — and What It Actually Proved

In December 2025, the Linux kernel received its first CVE (CVE-2025-68260) for Rust code. The vulnerability was found in the Rust Binder driver and involved a race condition in code explicitly marked unsafe — Rust’s opt-out mechanism for low-level operations that cannot be statically verified.

Rather than undermining confidence in Rust, this incident actually validated its value proposition. The bug was in deliberately unsafe code — precisely the category Rust forces developers to isolate and label. The vast majority of Rust kernel code, which operates under full safety guarantees, was unaffected. The CVE demonstrated that Rust’s safety model works as designed: when vulnerabilities exist, they are confined to explicitly unsafe regions that developers know to scrutinise.

Broader Ecosystem Momentum

The permanence of Rust in the kernel is reinforced by adoption throughout the wider Linux ecosystem. Debian, one of the most influential Linux distributions and the upstream base for Ubuntu, announced that Rust would become a hard dependency in its foundational APT (Advanced Package Tool) package manager no earlier than May 2026. This means even users who never write a line of Rust will soon depend on Rust-compiled components in their systems.

A parallel technical development also signals long-term commitment: the gccrs project, which implements a Rust compiler on top of the GCC (GNU Compiler Collection), is actively being developed with building the Linux kernel as one of its top priorities. When complete, this will allow the kernel to be built with Rust using the same compiler infrastructure traditionally used for C, potentially easing toolchain concerns.

So Will Rust Replace C?

The answer, supported by every piece of available evidence, is: no — not in any meaningful timeframe, and probably not ever in a wholesale sense. But that framing misses the point.

A full rewrite of the Linux kernel in Rust would take decades, would require rebuilding an enormous ecosystem of tools, debugging infrastructure, and institutional knowledge, and would break compatibility with thousands of existing kernel modules. The kernel is, as one analysis put it, an evolutionary project, not a revolutionary one.

What is actually happening is more nuanced and arguably more important: Rust is becoming the default language for new kernel development in security-sensitive and driver-level code, while C continues to maintain the vast legacy codebase. The two languages will coexist, with Rust gradually expanding its territory over years and decades.

For the next generation of kernel and systems programmers, the practical implication is clear: deep knowledge of C remains essential for understanding and maintaining the existing kernel, but fluency in Rust is becoming a core career skill. The combination of both — understanding C’s low-level control alongside Rust’s safety guarantees — will define the next generation of systems developers.

Conclusion

The question ‘will Rust replace C?’ is less interesting than the reality: Rust has already secured a permanent and expanding role in the Linux kernel.

The December 2025 Tokyo summit decision did not mark the beginning of a replacement — it marked the end of an argument. Rust is no longer an experiment.

It is, alongside C, part of the foundation on which the world’s most widely deployed operating system will continue to be built. The two languages are not rivals. They are, increasingly, partners.

Sources: The New Stack, devclass.com, Slashdot, Medium — reflecting developments through early 2026.

Will Rust Replace C in the Linux Kernel?