Updated: 2026-06-20

Rust in the Linux kernel moved from “interesting idea” to operational reality during 2022–2024. Linux 6.1 (December 2022) merged initial support. Linux 6.9 (May 2024) brought significant advances: merged experimental drivers, community frameworks, and the first real Rust-in-kernel cases versus ongoing direction debate. This article covers the real state and what it means for OS security.

Key takeaways

  • 70 % of kernel vulnerabilities are memory safety bugs; Rust eliminates them at compile time.
  • The Asahi Linux GPU driver (Apple Silicon), written entirely in Rust, proves the approach works in real production.
  • Rust is additional, not a C replacement: the consensus is “new drivers can choose Rust, core kernel stays in C.”
  • The main friction is not technical but organisational: some maintainers refuse to review or maintain Rust bindings.
  • For systems programmers learning Rust, there is a real opportunity to contribute now.

The problem Rust addresses

The statistics are consistent across different projects:

  • 70 % of kernel vulnerabilities are memory safety bugs: use-after-free, buffer overflows, data races.
  • C makes preventing these bugs hard: code review can detect them but not systematically eliminate them.
  • Rust’s ownership model makes these bug classes impossible at compile time.

For a kernel with tens of millions of lines of code and thousands of contributors, introducing a memory-safe language is a long-term strategic decision, not an aesthetic preference.

State in Linux 6.9

Components merged into the main tree:

  • Rust abstractions layer: kernel API bindings (memory, synchronisation, I/O).
  • Sample drivers: hello world and echo examples.
  • Infrastructure: crate management, testing framework.

Experimental drivers merged or in progress:

  • Partial NVMe driver in Rust: demonstrative POC.
  • Apple Silicon GPU driver (Asahi): written in Rust, already in production.
  • drivers/net/phy: some PHY drivers.

No critical mainline modules written only in Rust yet. Focus is on the abstractions layer and experimental drivers.

The Asahi driver: a successful proof of concept

Asahi Linux[1] — the project bringing Linux to Apple Silicon — wrote its entire GPU driver in Rust. This is:

  • A real driver, not an academic POC.
  • Running on thousands of Apple M1/M2 machines.
  • With performance comparable to native C drivers.
  • The most convincing demonstration that Rust in the kernel works.

Asahi chose Rust for a complex driver with significant state (GPU management, commands, memory synchronisation) — precisely where C tends to produce the subtlest bugs.

Why Rust versus C in the kernel

Concrete advantages:

  • Compile-time memory safety: use-after-free and data races are impossible by construction, not by discipline.
  • Explicit error handling: Result<T,E> instead of return codes that get forgotten.
  • Zero-cost abstractions: same performance as C, with more guarantees.
  • Clear ownership: who frees what is encoded in the types.
  • Modern tooling: rustfmt, clippy, cargo equivalent.

Disadvantages in kernel context:

  • High learning curve for C-accustomed developers.
  • Slower compile time than C.
  • Crate ecosystem different from the subset the kernel needs.
  • Change churn: Rust evolves fast; the kernel wants API stability.

The community debate

Tensions are real and public:

In favour of Rust:

  • Linus Torvalds approved inclusion, though cautiously.
  • Google (Android team), Microsoft (Azure Linux) and Red Hat are investing.
  • New drivers in some projects default to Rust.

With reservations:

  • Some subsystem maintainers refuse to review Rust code for their areas.
  • Dual complexity (C API + Rust bindings) increases maintenance burden.
  • Rust bindings break with internal kernel changes more easily than C code.

The 2024 drama: some subsystem maintainers publicly declared they will not maintain corresponding Rust bindings, requiring Rust contributors to assume that responsibility.

Tentative consensus

The community position, though not formally written:

  • Rust is additional, not a C replacement.
  • New drivers can choose Rust if the subsystem maintainer agrees.
  • Core kernel (scheduler, MM, critical FS) stays in C for now.
  • Gradual evolution, no big-bang conversion.

How to start contributing

For developers wanting to experiment with Rust in the kernel:

  1. Read the Rust for Linux[2] documentation.
  2. Compile a kernel 6.1+ with Rust support enabled.
  3. Explore sample drivers in samples/rust/ of the kernel tree.
  4. Write a toy driver for simple hardware.
  5. Contribute abstractions to the rust-for-linux tree.

The learning curve is real — it requires knowing both Rust and kernel internals — but it is the most concrete opportunity the kernel has offered new contributors in years.

Projected security impact

If half the new kernel code were in Rust in 5–10 years:

  • CVE reduction: memory safety bugs represent 60–70 % of kernel CVEs. Reduction potential is massive.
  • Stronger supply chain: third-party drivers with stronger security guarantees.
  • Safer refactoring: structural changes are verified by the compiler.

Does not solve logic bugs, complex concurrency, or hardware issues, but it is a significant structural improvement.

Conclusion

Rust in Linux is now reality, not promise. The Asahi driver proves the approach works for complex production drivers. The debate over adoption pace will continue — maintainers with reservations have legitimate concerns about added complexity — but the direction is unambiguous. For systems programmers learning Rust, there is a real opportunity to shape how the kernel evolves. For enterprises depending on Linux, it is a trend to follow: the C-only kernel era is closing, slowly but decisively.

  1. Asahi Linux
  2. Rust for Linux