Rust Enters the Linux Kernel — A Second Language in Mainline

Linux 6.1, released on 11 December 2022, looked like a routine release. Inside it sat one of the most unusual decisions in the kernel's history: initial Rust language support was officially merged.

Since Linus Torvalds released Linux in 1991, the kernel had been written in C plus architecture-specific assembly, and nothing else. Three decades without exception. Now a second language had landed in mainline.

What 6.1 Contained Was Scaffolding, Not Drivers

This is the part most often misread. What 6.1 merged was support for the Rust toolchain, a minimal set of kernel-side crates, and sample modules to prove the build worked. Not one production driver. The maintainers deliberately kept the first merge to the smallest thing developers could test against.

Torvalds had said in September 2022 that "Unless something odd happens, it will make it into 6.1"; the pull request was taken in October. The same expectation had already slipped once — of the 6.0 cycle he wrote, "I actually was hoping that we'd get some of the first rust infrastructure... but neither of them happened this time around."

Why Rust — The Memory-Safety Case

The largest single category of kernel bugs is memory-safety violations: use-after-free, double-free, out-of-bounds access, data races. In 2019 the Microsoft Security Response Center published that roughly 70% of the vulnerabilities it assigns CVEs to had been memory-safety issues, consistently, over the previous twelve years. The Chromium project analysed 912 high- and critical-severity security bugs since 2015 and found about 70% were memory-unsafety problems — half of them use-after-free. C cannot prevent any of this at the compiler level.

Rust's ownership model and borrow checker eliminate most of it at compile time. The adoption argument was never "rewrite the kernel". It was narrower: write new code, especially drivers, in Rust, and that new code is memory-safe. Existing C stays C.

Miguel Ojeda and Rust for Linux

The effort was led by Miguel Ojeda. Rust for Linux (R4L) surfaced publicly on the kernel mailing list in 2020, with serious patch series from 2021.

Torvalds, famous for his dismissal of C++ and conservative about language choice in Linux, gave two reasons for accepting Rust: the memory-safety argument was technically sound, and a project that cannot attract a new generation of developers has a sustainability problem. It was not a position about language aesthetics.

The 2025 Conflict — Over the DMA Subsystem

The technical merge advanced. The cultural one did not. The flashpoint came in January 2025 with a patch titled "rust: add dma coherent allocator abstraction" — a proposal to put, under rust/kernel, the abstraction that lets a Rust-written driver call the kernel's C DMA API.

Christoph Hellwig — maintainer of the DMA subsystem, one of the kernel's core C maintainers and the original author of the NVMe driver — replied on 8 January with "No Rust code in kernel/dma, please," despite the patch placing nothing in that directory. On 10 January: "Don't force me to deal with your shiny language of the day. Maintaining multi-language projects is a pain I have no interest in dealing with." On 28 January: "If you want to make Linux impossible to maintain due to a cross-language codebase, do that in your driver so that you have to do it instead of spreading this cancer to core subsystems." In the same message he specified that "this cancer explicitly is a cross-language codebase and not Rust itself."

R4L's position was the inverse: the Rust-side abstractions are maintained by the Rust side; nobody is asking C maintainers to read Rust.

Hector Martin's Exit — and What Torvalds Actually Ruled

Hector Martin, project lead of Asahi Linux (Linux on Apple Silicon Macs), was writing an Apple GPU driver in Rust. He pressed Torvalds on the list for an authoritative ruling and defended public criticism as a tool against maintainers hostile to Rust: "If shaming on social media does not work, then tell me what does, because I'm out of ideas…"

Torvalds' reply on 6 February 2025 was blunt: "How about you accept the fact that maybe the problem is you." He went on: "However, I will say that the social media brigading just makes me not want to have anything at all to do with your approach," and "Technical patches and discussions matter. Social media brigading - no thank you."

Martin asked to be removed as upstream maintainer for Apple Arm support shortly afterwards, and on 13 February 2025 resigned as Asahi Linux project lead, citing burnout, demanding users, and loss of faith in the leadership. R4L had already lost Wedson Almeida Filho, a Microsoft engineer, in August 2024 on similar grounds.

But Torvalds' ruling did not affirm a maintainer veto. In an email on 20 February 2025 he drew the line the other way: "as a maintainer you are in charge of your code, sure - but you are not in charge of who uses the end result and how." And: "You can't have it both ways. You can't say 'I want to have nothing to do with Rust', and then say the Rust code cannot use the C interfaces I maintain." No maintainer is required to read Rust; no maintainer may block Rust code from calling the C interfaces they own.

When the Drivers Actually Arrived

Three years after 6.1, real Rust code landed in stages.

Rust Binder also produced the first CVE against kernel Rust code (CVE-2025-68260, a race condition, affecting 6.18 and later) — a reminder that memory safety does not eliminate logic errors or races.

The End of the Experiment

In December 2025 the Linux Kernel Maintainers Summit treated the Rust experiment as concluded. Miguel Ojeda posted a patch deleting the "The Rust experiment" section from the kernel documentation, writing: "The experiment is done, i.e. Rust is here to stay." His stated reason for the deletion was that the text no longer matched reality — Rust was already in production, enabled by well-known distributions, and shipping in millions of devices through Android.

In the graphics (DRM) subsystem, maintainers have since discussed restricting new drivers to Rust.

The "We Write in C" Rule, Amended

Rust's arrival in the kernel is not merely the addition of a language. It is the moment the most influential open-source operating-system project updated its unwritten rule that "we write in C".

It also made visible the human cost of introducing a new language into a large volunteer project: cultural collisions, maintainer departures, the difficulty of adjudication.

And one correction worth stating plainly at the end. Rust has not replaced C in the kernel, and has not begun to. As of Linux 7.1 in mid-2026, Rust is about 0.31% of the kernel tree by source lines — roughly 93,000 SLOC against 30 million, and about half of that is vendored third-party crates. There is no plan to rewrite existing C. What happened is that some of the code written from now on can be written in Rust — and that, after thirty years, was the structural change.