Why Did Linux Kernel Maintainers Choose Rust Over C?

Why Did Linux Kernel Maintainers Choose Rust Over C?

After five years of experimentation, debate, and steady progress, Rust has officially become a core programming language in the Linux kernel.

In December 2025, at the Linux Kernel Maintainers Summit in Tokyo, the world’s leading kernel developers reached a historic consensus: Rust is no longer experimental—it’s here to stay.

This decision marks one of the most significant technological shifts in the history of the Linux kernel, which has relied almost exclusively on C and assembly since its creation in 1991.

To understand why this matters, we need to examine the problem Rust solves, the journey to its adoption, and what this means for the future of operating systems.

The Memory Safety Crisis

The catalyst for Rust’s entry into the Linux kernel came from a sobering realization about security vulnerabilities. In 2019, at the Linux Security Summit, researchers Alex Gaynor and Geoffrey Thomas presented data showing that approximately two-thirds of all Linux kernel vulnerabilities stemmed from memory safety issues—buffer overflows, use-after-free errors, null pointer dereferences, and data races.

C, the language that has powered the kernel for over three decades, provides developers with unparalleled control over hardware and exceptional performance. However, this power comes at a steep price: manual memory management. Every pointer allocation, every memory access, every concurrent operation relies on programmers getting it right, every single time. Human error is inevitable, and in kernel code, these errors often translate directly into security vulnerabilities that can compromise entire systems.

Traditional approaches to solving these problems—code reviews, static analysis tools, runtime sanitizers—have helped, but they haven’t eliminated the fundamental issue. The industry needed a solution that could prevent these bugs at compile time, before the code ever runs in production.

Why Did Linux Kernel Maintainers Choose Rust Over C?

Enter Rust: Safety Without Sacrifice

Rust, first released in 2010 and reaching stability in 2015, was designed from the ground up to address exactly these challenges. Through its ownership model, borrow checker, and lifetime system, Rust enforces memory safety and prevents data races at compile time. The language makes it impossible to accidentally trigger many classes of bugs that plague C code.

Critically, Rust achieves this safety without the performance overhead of garbage collection or runtime checks. For kernel development, where every nanosecond matters and direct hardware access is essential, this combination of safety and performance made Rust a compelling candidate.

The Journey to Acceptance

The path to Rust’s official adoption was neither quick nor easy.

2020: The Experiment Begins

The Rust for Linux project launched with a clear goal: not to rewrite the entire kernel, but to enable new code to be written in Rust where it could provide the most security benefit. The initial focus was on “leaf” components—drivers, subsystems, and helper libraries that interact with well-defined kernel APIs.

2022: Official Support

Linux kernel version 6.1, released in December 2022, merged the first infrastructure for Rust support. This was a critical milestone that allowed developers to begin writing and testing Rust code in non-critical kernel areas. Linus Torvalds, the kernel’s creator, signaled his support for the experiment, though he acknowledged it would take time to prove its value.

2023-2024: Real-World Implementation

The first Rust drivers were merged in late 2023 and released in Linux 6.8. Projects began to emerge:

GPU drivers for NVIDIA (Nova), Apple Silicon (Asahi), and ARM Mali (Tyr)
File system drivers like rust_ext2
The Binder IPC mechanism, fundamental to Android’s architecture

By April 2025, the kernel contained approximately 34 million lines of C code compared to just 25,000 lines of Rust—a tiny fraction, but one that was proving its worth in production environments.

December 2025: The Experiment Concludes

At the Kernel Maintainers Summit in Tokyo, consensus emerged among the assembled developers: Rust had proven itself. Miguel Ojeda, lead of the Rust for Linux project, submitted a formal patch removing the “experimental” label from the documentation. As kernel maintainer Steven Rostedt reported, “There was zero pushback.”

The decision was more than symbolic. It signaled that Rust support would be maintained long-term, that the infrastructure would continue to mature, and that new kernel code could be written in Rust with confidence.

Real-World Validation: Android 16

The strongest evidence of Rust’s success came from an unexpected source. During the summit, Ojeda revealed that Android 16 devices, based on Linux kernel 6.12, ship with the ashmem (anonymous shared memory subsystem) memory allocator completely rewritten in Rust. This means millions of consumer devices worldwide are already running production Rust code in their kernels.

For enterprise adoption, this is a crucial data point. Rust isn’t theoretical or experimental anymore—it’s powering the devices in people’s pockets.

The First CVE: A Learning Moment

In mid-December 2025, the Linux kernel received its first CVE (CVE-2025-68260) for Rust code. The vulnerability, found in the Rust Binder driver, involved a race condition in code marked as “unsafe”—Rust’s mechanism for bypassing safety checks when low-level operations require it.

Rather than undermining confidence in Rust, this CVE actually validated the language’s value proposition. The bug could only cause system crashes, not the remote code execution or privilege escalation typical of C memory corruption vulnerabilities. As Greg Kroah-Hartman, a senior Linux kernel developer, noted: the vulnerability “just causes a crash, not the ability to take advantage of the memory corruption, a much better thing overall.”

On the same day this Rust CVE was announced, 159 CVEs were issued for the C portions of the kernel—a stark reminder of the scale of the memory safety problem Rust is designed to address.

The incident highlighted an important principle: Rust’s safety guarantees only apply to “safe” code. Kernel development requires frequent use of “unsafe” blocks for hardware access and performance-critical operations. However, Rust’s design makes these dangerous sections explicit and isolated, making them easier to audit and review compared to C, where the entire codebase is inherently “unsafe.”

Advantages Driving Adoption

The benefits of Rust in the kernel are becoming increasingly clear:

Memory Safety: By preventing entire classes of bugs at compile time, Rust reduces the attack surface for malicious actors and the maintenance burden for developers.

Concurrency Without Fear: Rust’s ownership system prevents data races, making it safer to write concurrent code—increasingly important as hardware becomes more parallel.

Better Error Handling: Rust’s Result and Option types make error handling explicit and mandatory, reducing the likelihood of unhandled edge cases.

Attracting New Developers: Rust’s modern tooling, comprehensive documentation, and growing ecosystem make kernel development more accessible to a new generation of programmers who might find C daunting.

Industry Momentum: Major technology companies including Google, Microsoft, and Amazon have embraced Rust for systems programming, creating a deep talent pool and robust toolchain.

Challenges and Pragmatism

The adoption of Rust in the Linux kernel has not been without friction. Some kernel maintainers expressed concern about:

Learning Curve: Rust’s concepts (ownership, lifetimes, borrowing) require significant investment to master.
Toolchain Dependencies: Rust requires a specific compiler version and tools like bindgen for C interoperability.
Architecture Support: Some less-common architectures have limited or no Rust support.
Increased Maintenance Burden: Supporting both C and Rust increases complexity for maintainers.

These concerns are real and valid. However, at the Tokyo summit, the consensus was clear: the benefits outweigh the costs. As Greg Kroah-Hartman noted in a compelling mailing list post, drivers written in Rust are proving safer than those in C, and the interoperability issues between Rust and C have been fewer than expected.

The Path Forward

The removal of the “experimental” label doesn’t mean the work is done—it means the foundation is solid enough to build on. Several significant developments are on the horizon:

Distribution Requirements: The Debian project has announced that Rust will be a required dependency in its APT package manager starting in May 2026. This signals that major Linux distributions are committed to supporting Rust in their kernels.

Graphics Subsystem Transition: Dave Airlie, maintainer of the DRM (Direct Rendering Manager) subsystem crucial for graphics, stated at the summit that DRM is about a year away from requiring Rust for new drivers and potentially disallowing C for new driver submissions.

Compiler Development: The gccrs project, implementing Rust on top of the GNU Compiler Collection, is actively working to support kernel builds. The plan is that it will always be possible to build the kernel with the version of Rust included in the latest Debian stable release.

Expanding Use Cases: While Rust won’t replace all C code in the kernel, new development is increasingly likely to use Rust, especially for drivers, file systems, and network subsystems where memory safety is paramount.

What This Means for the Industry

The Linux kernel’s embrace of Rust has implications far beyond Linux itself:

Setting a Standard: As the world’s most widely deployed open-source operating system kernel, Linux’s adoption of Rust validates the language for systems programming at the highest level.

Influencing Other Projects: Operating systems and embedded projects are watching closely. Windows has experimented with Rust, and other kernels may follow Linux’s example.

Changing Career Paths: For current and aspiring kernel developers, proficiency in both C and Rust is becoming increasingly valuable. The combination of deep C knowledge with Rust’s safety guarantees may define the next generation of systems programmers.

Security-First Mindset: The move to Rust reflects a broader industry shift toward making security a design-time concern rather than a runtime problem to be solved through patches.

Conclusion

The decision to make Rust a permanent part of the Linux kernel represents a pragmatic evolution, not a revolution. C and assembly aren’t going anywhere—the kernel’s 34 million lines of existing C code work well and have been battle-tested for decades. But for new code, Rust offers compelling advantages that are impossible to ignore.

Memory safety vulnerabilities have plagued software for as long as we’ve been writing it. They consume enormous resources in testing, debugging, and security patching. They create exploitable weaknesses that put users at risk. Rust offers a practical path to eliminating entire categories of these problems.

As Miguel Ojeda put it, “Rust is here to stay.” After five years of experimentation, millions of devices in production, and consensus among the world’s leading kernel developers, that’s no longer a prediction—it’s a reality.

The Linux kernel’s journey with Rust is still in its early chapters, but the direction is clear: toward a more secure, reliable, and maintainable foundation for the computing infrastructure that powers our world.

This article reflects developments through early 2026, including the December 2025 Kernel Maintainers Summit decision to remove Rust’s experimental status, the deployment of Rust code in Android 16, and the first Rust CVE in the Linux kernel.