Rust in the Linux Kernel: What It Means in 2026

By Rustify Team, updated March 2026

TL;DR: Rust was accepted into the Linux kernel in October 2022 (kernel 6.1). By 2026, Rust kernel code is shipping in production: Android's Binder IPC driver has a Rust implementation, Apple's GPU driver (asahi-gpu) is Rust, and multiple filesystem and network subsystems have Rust contributions. This is the biggest architectural change in the Linux kernel in decades.

• Kernel 6.1 (Dec 2022): First Rust infrastructure merged : rust/ directory, Rust build system
• Kernel 6.2–6.5: Core abstractions: drivers, memory allocators, filesystem bindings
• Kernel 6.6+ (2023–2026): Apple GPU driver (asahi), Android Binder rewrite, NVMe driver
• Why it matters: Memory safety eliminates entire CVE categories : buffer overflows, use-after-free, data races
• What doesn't change: C remains the dominant kernel language : Rust is an opt-in addition, not a replacement

Who Should Read This?

This article is for systems programmers, kernel contributors, and senior engineers who want to understand how Rust's acceptance in the Linux kernel changes the landscape for low-level development in 2026. If you write device drivers, contribute to open source kernel subsystems, work in cloud infrastructure where custom kernel modules appear, or simply want to know whether "Rust in the kernel" is hype or substance, this guide is for you. Kernel Rust engineers are rare : the intersection of deep kernel knowledge and Rust proficiency commands some of the highest compensation in systems programming, with senior roles at cloud and semiconductor companies reaching $195K–$250K in the US.

How Did Rust Get Into the Linux Kernel?

Rust in the Linux kernel started as a years-long proposal by Miguel Ojeda, accepted by Linus Torvalds in October 2022 : the first new language accepted in the kernel since C replaced assembly in the early kernel years.

The journey from proposal to merge spanned three years:

Linus Torvalds's position evolved from skepticism to acceptance: he acknowledged that the kernel's primary security problem : memory safety bugs : was something C could not solve, and Rust addressed it at the type system level. Engineers who specialize in this space : Rust kernel contributors at companies like Google, Meta, and Microsoft : earn $180K–$250K in the US, making the kernel track one of the highest-paying Rust specializations available today.

What nobody tells you about Rust in the kernel: Rust kernel code does not use the standard library : it runs in a fully no_std environment with a custom kernel crate that provides its own allocator, synchronization primitives, and collection types. Many Rust patterns you know from userspace : std::sync::Mutex, Vec::new(), Box, thread::spawn : either don't exist or behave differently in kernel space. The mental model shift required is significant: you are not writing "Rust with kernel APIs bolted on," you are writing a different dialect of Rust where most of the standard playbook doesn't apply.

The acceptance was not unanimous. Several kernel maintainers raised concerns about increased build complexity, the requirement for a Rust toolchain in the build environment, and the learning curve for existing contributors. These concerns led to a strict opt-in policy: Rust is only compiled when explicitly enabled (CONFIG_RUST=y), and C code can never depend on Rust code at link time. This architectural decision ensured that the Linux kernel's enormous existing C contributor base was not disrupted by the addition.

What Kernel Components Are Written in Rust in 2026?

The most significant Rust kernel components in 2026 are the Android Binder IPC driver, the Apple GPU (asahi) driver, and NVMe infrastructure : with ongoing work on networking and filesystem abstractions.

The asahi GPU driver is particularly significant: it's an entire complex driver written from scratch in Rust, not a port of C code. It implements the full Apple Silicon GPU command queue, memory management, and DMA interfaces : proving that Rust can handle the most complex kernel subsystems.

By 2026, the kernel crate's API surface has stabilized enough that driver authors can write against a reasonably stable Rust kernel API, rather than rewriting their drivers with every kernel release. This stability was a major concern in the early days : kernel C APIs themselves change frequently, and Rust wrappers for those APIs necessarily change with them. The rust_out_of_tree abstraction layer helps by decoupling driver code from the lowest-level kernel bindings.

Why Is Rust Being Added to the Kernel?

70–80% of Linux kernel CVEs are memory safety vulnerabilities : buffer overflows, use-after-free bugs, and race conditions. Rust's type system makes these classes of bugs compile-time errors rather than runtime exploits.

This is not theoretical. The National Security Agency (NSA) and CISA both published guidance in 2022–2023 explicitly recommending Rust and other memory-safe languages for systems programming, citing kernel vulnerabilities as the primary threat vector.

CVE categories addressed by Rust:

The Android security team has tracked that zero memory safety vulnerabilities have been found in Rust Android code since adoption began : versus hundreds per year in C/C++ code in the same codebase.

The kernel is a particularly high-value target because a single kernel vulnerability can compromise an entire system regardless of what userspace security measures are in place. Kernel exploits bypass sandboxes, container isolation, and application-level security entirely. The NSA's 2022 guidance specifically cited Linux kernel vulnerabilities when recommending memory-safe languages : a direct influence on the US government's own cybersecurity posture for critical infrastructure.

Rust vs C for Kernel Development

The tradeoff is clear: Rust costs more upfront (steeper learning curve, slower compile times) in exchange for eliminating entire CVE categories at the type system level. For security-sensitive kernel subsystems : drivers handling untrusted hardware, IPC mechanisms, network stacks : that tradeoff is increasingly considered worthwhile by kernel maintainers and major industry contributors alike.

Bottom line: For new kernel drivers and security-sensitive subsystems, Rust is the clear choice in 2026 : it eliminates use-after-free, buffer overflow, and data-race CVEs at compile time; C remains dominant for the existing 20M-line codebase but is no longer the default for net-new work.

What Does Writing Kernel Code in Rust Look Like?

Rust kernel code uses safe wrappers around C kernel APIs : the kernel crate provides Rust abstractions for spinlocks, reference counting, memory allocation, and device registration that enforce kernel programming rules at compile time.

A minimal Rust kernel module:

// Rust kernel module structure (kernel 6.8+ API)
use kernel::prelude::*;
 
module! {
    type: MyModule,
    name: "my_module",
    author: "Author Name",
    description: "A minimal Rust kernel module",
    license: "GPL",
}
 
struct MyModule;
 
impl kernel::Module for MyModule {
    fn init(_module: &'static ThisModule) -> Result<Self> {
        pr_info!("Rust module loaded\n");
        Ok(MyModule)
    }
}
 
impl Drop for MyModule {
    fn drop(&mut self) {
        pr_info!("Rust module unloaded\n");
    }
}

A Rust character device driver:

use kernel::{
    file::{File, Operations},
    io_buffer::{IoBufferReader, IoBufferWriter},
    miscdev::Registration,
    prelude::*,
    sync::Mutex,
};
 
struct MyDevice {
    data: Mutex<Vec<u8>>,
}
 
#[vtable]
impl Operations for MyDevice {
    type Data = Arc<MyDevice>;
 
    fn read(data: ArcBorrow<'_, MyDevice>, _file: &File, writer: &mut UserSlicePtrWriter, offset: u64) -> Result<usize> {
        let locked = data.data.lock();
        // Copy kernel data to user space safely
        let bytes_written = writer.write_slice(&locked[offset as usize..])?;
        Ok(bytes_written)
    }
 
    fn write(data: ArcBorrow<'_, MyDevice>, _file: &File, reader: &mut UserSlicePtrReader, _offset: u64) -> Result<usize> {
        let mut locked = data.data.lock();
        let len = reader.len();
        locked.resize(len, 0);
        // Copy user space data to kernel safely
        reader.read_slice(&mut locked)?;
        Ok(len)
    }
}

The key insight: the kernel crate wraps unsafe C kernel operations in safe Rust APIs. The device write operation above handles the user-space/kernel-space memory copy : a historically dangerous operation prone to buffer overflows : with bounds checking enforced at the type level.

The kernel crate's Mutex is not the standard library's std::sync::Mutex. It wraps the kernel's struct mutex and enforces kernel-specific rules: mutexes cannot be held while in interrupt context, and the MutexGuard carries lifetime information that prevents use after the lock is released. These are invariants that C developers must track mentally; in Rust they are enforced by the type system.

What Does This Mean for Rust Developers?

Rust's acceptance in the Linux kernel is the strongest possible signal that Rust is appropriate for the most critical, performance-sensitive, low-level systems code in existence : removing any remaining doubt about Rust's technical suitability for systems programming.

Practical implications for Rust developers:

1. Kernel development is now accessible: Historically kernel development was C-only. Rust kernel bindings lower the barrier for application developers to contribute to kernel code without deep C expertise.

2. Linux Foundation and Google investment: Google funds Rust Linux development directly (Miguel Ojeda's salary), and the Linux Foundation has committed resources. The project will continue growing.

3. Career opportunity: Rust kernel developers command significant premium : the intersection of kernel expertise and Rust skills is rare. Companies building embedded Linux products, Android devices, and cloud infrastructure are hiring. Compensation at companies like Google, Cloudflare, and semiconductor firms for kernel Rust roles ranges from $185K to $260K in the US.

4. Validation effect: When your language is good enough for the Linux kernel, the "is Rust production-ready?" question is definitively answered.

For Rust engineers entering this space, the recommended starting point is the rust-for-linux GitHub repository, which maintains documentation, example drivers, and the kernel crate. Running a Rust-enabled kernel build in a QEMU virtual machine is achievable in an afternoon. The Rust out-of-tree module template gives you a starting point for a kernel module without cloning the entire kernel tree.

Bottom line: The intersection of kernel expertise and Rust proficiency is genuinely rare : senior roles at cloud and semiconductor companies reach $195K–$260K in the US, and demand is growing as more kernel subsystems adopt Rust.

What Common Mistakes Do Kernel Rust Developers Make When Starting Out?

Writing Rust kernel code has sharp edges that differ significantly from userspace Rust : these are the mistakes that trip up even experienced Rust developers.

• Reaching for std types that do not exist in kernel context. Kernel Rust operates in a no_std environment. Types like Vec, String, Box, and Arc exist but are re-exported from the kernel crate with kernel-specific allocators. Importing std::sync::Mutex will not compile. Always use kernel::prelude::* and the types provided by the kernel crate, not the standard library.

• Holding locks across scheduling points. In the Linux kernel, holding a spinlock while calling any function that might sleep or schedule is a deadlock. The kernel::sync::SpinLock type in Rust enforces some of these rules via guard types, but not all: in particular, async-adjacent patterns are not safe in spinlock context. Study the kernel's locking rules (Documentation/locking/) before writing concurrent kernel Rust.

• Ignoring the must_use annotations on kernel error types. The kernel crate uses Result<T, kernel::Error> extensively, and #[must_use] is applied. Silently ignoring errors with let _ = ... is a common mistake that hides real failures. Always handle kernel errors explicitly.

• Assuming LLVM version compatibility with upstream Rust. The kernel pins to a specific minimum LLVM/Rust version and does not always track the latest stable Rust. Code that uses features available in Rust 1.78 may not compile against the kernel's supported Rust version. Check the rust-version field in the kernel's build documentation before using newer language features.

• Misunderstanding unsafe scope in kernel FFI. When calling raw kernel C functions via the auto-generated bindings in bindings::, the entire call must be inside unsafe. But kernel Rust philosophy is to minimize the scope of unsafe blocks. A common mistake is wrapping entire functions in unsafe rather than wrapping only the specific FFI call and providing a safe interface. Keep unsafe blocks as small as possible.

• Not testing against the CONFIG_RUST=y kernel build. Many Linux distributions do not yet enable Rust by default. Developers test their module against a standard kernel build and only discover Rust-specific build failures when submitting upstream. Always build and test against a CONFIG_RUST=y kernel: the virtme-ng tool simplifies this workflow by booting a kernel in a VM from a local source tree.

Frequently Asked Questions

Related Glossary Terms

• Ownership: The core reason Rust is suitable for kernel development : no GC, no hidden allocations
• Borrow Checker: Enforces memory safety without a kernel-level allocator or runtime
• Lifetime: Ensures references in kernel code never outlive the objects they point to

Keep Reading

• Rust Memory Safety: Why NSA and CISA Recommend Rust in 2026
• Rust in the Windows Kernel: Microsoft's Big Bet on Rust
• Rust vs C++: Which Should You Learn in 2026?

Sources

• Linux kernel: Rust documentation
• Linus Torvalds accepting Rust, kernel mailing list (October 2022)
• Miguel Ojeda: Rust for Linux announcement (kernel 6.1)
• Android Binder driver Rust implementation
• asahi-gpu: Apple GPU driver in Rust (Asahi Linux)
• NSA Cybersecurity: Software Memory Safety guidance (November 2022)
• Google: Android memory safety

If you want a structured path from Rust fundamentals to low-level systems work like kernel module development, Rustify's 9-week bootcamp covers unsafe Rust, FFI, and systems programming patterns with 1:1 coaching : giving you the foundation needed to contribute to projects like rust-for-linux.