Rust in the Linux Kernel Goes Mainstream: What It Means for Embedded and IoT Drivers

For roughly five years, anyone shipping a product on embedded Linux could treat Rust as a curiosity: interesting, upstream, and safely ignorable. That stopped being true in December 2025, when the assembled maintainers at the Linux Kernel Maintainers Summit in Tokyo deemed the experiment concluded, and the project’s lead, Miguel Ojeda, sent a patch deleting the “experimental” language from the kernel documentation. Rust in the Linux kernel is now a permanent, supported part of the tree, already shipping on Android devices and in distribution kernels.

That matters for IoT teams because the decision changes the economics of the one artifact most of them cannot avoid: the vendor board support package, with its pile of out-of-tree drivers. Memory-safety bugs in that code are the most expensive class of defect on devices you cannot easily patch. The question is no longer whether Rust will reach your kernel, but when your toolchain, your CI, and your driver strategy have to accommodate it.

This article separates what is verified from what is hype, explains how a Rust driver actually sits on top of C subsystem code, and gives a concrete decision framework for out-of-tree driver work.

What this covers: what changed and when, how Rust drivers are structured, the toolchain and Yocto/Buildroot cost, a decision matrix for new driver work, failure modes, and a checklist.

Context and Background

Rust support was merged into mainline in Linux 6.1, with the explicit purpose, in Ojeda’s own words, “to help determine whether Rust as a language was suitable for the kernel.” It was a trial with an exit condition. The case for it was old and simple: coverage of the project repeatedly cites that roughly two-thirds of Linux kernel vulnerabilities originate in memory-safety errors, the use-after-free, out-of-bounds and data-race classes that C leaves entirely to the programmer. Alex Gaynor and Geoffrey Thomas made that argument at the 2019 Linux Security Summit, and the Linux Plumbers conference picked up the integration question in 2020. Miguel Ojeda submitted the first Rust for Linux pull request in September 2021.

The trial was never about rewriting the kernel. As of April 2025, press coverage of the project counted about 34 million lines of C against roughly 25,000 lines of Rust, a ratio that makes the “rewrite” framing absurd. The strategy was always leaf code: new drivers, helper libraries, and subsystems at the edges, where a bug stays local and the interface to the rest of the kernel is narrow. Network, storage and GPU drivers are the typical targets.

What the Tokyo summit settled was not a technical question but a social one. Steven Rostedt, a kernel maintainer, said there was “zero pushback,” and Jonathan Corbet’s LWN coverage summarized the outcome as Rust being “no longer experimental, it is now a core part of the kernel.” The evidence the maintainers weighed was concrete. Android 16 devices running the 6.12 kernel ship ashmem, the anonymous shared memory subsystem, implemented in Rust, which means millions of production devices already depend on it. The Android binder driver, the inter-process communication backbone through which the majority of Android IPC flows, was merged in Rust form for 6.18. Debian has enabled Rust in kernel builds for its upcoming release, and Greg Kroah-Hartman reported that interactions between Rust drivers and the C core were fewer than he expected and that the Rust drivers were proving “far safer” than C equivalents.

Two caveats belong here. First, the LWN account noted that no CVEs had been assigned to Rust code at the time of writing; that is an encouraging data point, but it reflects a small, young code base and should not be read as a safety guarantee. Second, the dates require care: the documentation patch was posted on 12 December 2025, and Linux Magazine’s coverage of the 7.0 release reports the experimental label as removed in that kernel. I could not pin the exact merge commit, so this article says “by Linux 7.0” rather than naming a precise release candidate.

For readers working on the firmware side of the same language shift, our piece on Rust for no_std firmware on microcontrollers covers the bare-metal world; this article deals with the other half of the stack, the Linux-class devices where the kernel itself is the attack surface. The official statement of the change is in the kernel’s own Rust documentation.

Figure 1: Milestones for Rust in the Linux kernel, from the 6.1 merge through toolchain minimums. Kernel versions are as cited in the Rust for Linux version policy and release coverage.

The diagram reads left to right. The early years were advocacy, the 6.1 merge started the trial, 6.11 through 6.18 produced the first drivers that real products depend on, and the December 2025 summit converted a trial into a commitment. The toolchain minimums on the right matter as much as the drivers, because they decide what your build system must provide.

How Rust Drivers Actually Work: The Reference Architecture

A Rust driver in the kernel is a thin layer of safe Rust over hand-written safe abstractions, which wrap bindgen-generated bindings to the existing C subsystem. The C core is not replaced; Rust drivers call it through audited unsafe boundaries, and the compiler enforces ownership, lifetimes and error handling in everything above those boundaries.

Figure 2: Layering of a Rust driver. Drivers contain no unsafe code in the ideal case; unsafe lives in the abstraction layer, where each block carries a SAFETY comment.

The diagram shows four layers. At the bottom sits the C subsystem core that has existed for decades: the DRM graphics stack, the PCI and platform bus code, and so on. Above it, bindgen generates raw foreign-function-interface (FFI) declarations from kernel headers. Above that sit the Rust abstractions, hand-written modules that wrap those raw bindings in types whose invariants the compiler can check. At the top is the driver, which should contain no unsafe at all.

The abstraction layer is the real product

The most important thing to understand about Rust for Linux is that the language alone does not buy safety; the abstractions do. A C driver that registers an interrupt handler must remember to free the IRQ on every error path and on unload, and the compiler cannot tell it when it forgot. A Rust abstraction models the registration as an owned value: when the value goes out of scope, the destructor unregisters the handler. The same pattern applies to memory-mapped I/O regions, DMA buffers, clocks, regulators and device references. Resource lifetime becomes a property of the type system rather than a code-review checklist item.

This is also why the project concentrated first on infrastructure rather than drivers. Abstractions have to be designed once, reviewed hard by the subsystem maintainers who understand the C-side invariants, and then reused by every driver. Each unsafe block in an abstraction is expected to carry a comment justifying why the call upholds the C API’s contract. The review burden concentrates where the risk is, and a driver author who never writes unsafe cannot introduce the classic memory bugs, only logic bugs.

Pinned initialization and fallible allocation

Two language-level details separate kernel Rust from application Rust. The kernel cannot use the standard library’s infallible allocation, because an allocation failure in kernel context must be handled, not turned into a panic. Rust for Linux provides its own allocation APIs that return Result, and the kernel’s crates build on core plus a small alloc derived for kernel use. Second, kernel objects are frequently address-sensitive: a mutex or a list head embedded in a structure must not move after initialization. The kernel’s pin-init machinery lets a driver construct such objects in place and expresses “this value never moves” in the type system, which is how Rust can safely embed C-style intrusive structures.

The practical consequence for a driver author is that error handling is not optional. Functions return Result, the ? operator propagates failure, and cleanup runs through destructors. The error-path leak class, which is a staple of kernel CVE lists, is structurally harder to write.

What the in-tree drivers show

Several landed or in-progress drivers illustrate the range. The DRM panic QR-code screen, written by Jocelyn Falempe, is a 1,004-line Rust encoder (drm_panic_qr.rs) that renders kernel panic text as a QR code. It runs during panic handling, where the code cannot allocate memory or take locks, and it uses only core functions with two C entry points. Falempe was candid in the submission that there was “no particular reason to do it in rust, I just wanted to learn rust, and see if it can work in the kernel.” That is the point: a self-contained, no-allocation algorithm is an ideal first Rust component.

At the other end, Tyr is a Rust driver for Arm Mali GPUs created by Collabora with Google and Arm, positioned as a future replacement for the C Panthor driver; it supports the same Mali Command Stream Firmware (CSF) GPU set. It entered Linux 6.18 in an initial form that could power up the GPU and report metadata to user space through the DRM ioctl interface, a long way from a full 3D driver. Nova targets NVIDIA GPUs built around the GPU System Processor (GSP) firmware, and the 6.18-era work Phoronix summarized included register-macro improvements, VBIOS fixes and firmware boot staging against development firmware r570.144. Both are explicitly work in progress, and this article does not claim they are usable for production graphics.

The binder driver sits between: a full-scale Rust rewrite of a security- and performance-critical C driver, authored originally by Wedson Almeida Filho and now maintained by Alice Ryhl in the Android Open Source Project, merged for 6.18-rc1. The project’s page offers no benchmark numbers, so I make no performance claim either way.

What the Ecosystem Looks Like in 2026

The mainstream moment is as much about distribution and toolchain policy as about drivers, because that is what determines whether your build can accept Rust code at all.

Toolchain minimums and the Debian-stable policy

The kernel’s documented minimum software versions list Rust 1.85.0 and bindgen 0.71.1 as optional dependencies (needed only when CONFIG_RUST is enabled), alongside GNU C 8.1 and an optional Clang/LLVM 17.0.1. The Rust for Linux version policy states that the project follows Debian Stable’s Rust version as the minimum, adopting a new floor some months after Debian releases to give developers time to upgrade. Under that policy the minimum was 1.78.0 starting with Linux 6.11, and it moved to 1.85.0 in Linux 7.1, following Debian 13 “Trixie”, which released on 9 August 2025. The same policy page notes that the 6.18 stable series keeps 1.78.0 as its minimum.

That asymmetry is operationally important. If you ship a 6.18 LTS-based product, your Rust floor is old and stable. If you track mainline, the floor moves with Debian’s cadence. Pinning a kernel branch therefore also pins a toolchain window, and the two must be validated together.

Architecture coverage

The kernel’s Rust architecture-support table lists arm (ARMv7 little-endian only), arm64 (little-endian only), loongarch, riscv (riscv64 with LLVM/Clang only), s390 (with CONFIG_EXPOLINE disabled), um (user-mode Linux) and x86 (x86_64 only), all at “Maintained” level. For IoT that is a good match with the common targets: Cortex-A application processors on arm64 and 32-bit ARMv7, and RISC-V 64-bit parts. Two gaps matter. 32-bit RISC-V and MIPS cores are not in the list, and a RISC-V target forces the LLVM toolchain rather than GCC. If your fleet includes older ARMv5 or ARMv6 silicon, or big-endian designs, Rust in your kernel is not available.

GCC-based compilers

LWN’s summit report described two efforts to remove the LLVM dependency: rustc_codegen_gcc, which grafts a GCC code generator onto the standard rustc front end, and gccrs, a fully GCC-based Rust compiler that can now compile kernel Rust code, though its correctness is still being worked on. For vendors with GCC-only certified toolchains, this is the development to watch, but today a Rust-enabled kernel build effectively needs rustc, libclang and bindgen.

Distributions and the pull of Debian

Debian enabling Rust in its kernel builds for the next release, and its separate decision to introduce hard Rust requirements into APT from May 2026, are signals that the language is entering the base layer of mainstream distributions. For embedded teams building on Debian-derived images that matters because the toolchain arrives with the base distribution rather than as a special project.

For the build-system view of embedded Linux images, our comparison of Yocto-based and Ubuntu-based Jetson production images shows how much of the real work in a BSP lives in the recipe layer rather than the kernel source.

Deeper Analysis: Builds, Drivers, and the Out-of-Tree Problem

The shift matters most where embedded teams spend their pain: the build pipeline and the out-of-tree driver. Both deserve a close look.

What a Rust-enabled kernel build costs

Enabling CONFIG_RUST adds a toolchain, not just a compiler flag. The kernel quick-start documentation lists the requirements: a recent rustc, the rust-src component (the standard library sources the kernel recompiles for its own target), bindgen, and a working libclang. Debian 13 and later, Fedora, Arch, Gentoo and openSUSE package these directly; Ubuntu 24.04 LTS and older need versioned packages such as rustc-1.85 and bindgen-0.71, and Ubuntu 26.04 LTS packages them unversioned. Developers can instead use rustup with rustup override set stable in the kernel directory, and bindgen can be installed with cargo install --locked bindgen-cli.

Figure 3: The Rust kernel build pipeline. Three tools feed the build: rustc with rust-src, clang with libclang, and bindgen. Yocto or Buildroot recipes must provision all three.

Yocto is the clearest embedded data point. A patch series from Wind River engineers on the Yocto Project’s OE-Core list proposes Rust support in the linux-yocto recipe: 15 patches adding clang, Rust native tools and bindgen as dependencies, installing the Rust standard library sources, enabling the kernel configuration options, adding test cases for kernel Rust samples, and supporting out-of-tree Rust kernel modules, including from the SDK. The cover letter reports build-testing on qemuarm64 and qemux86-64 and, importantly, a cost: build time rose from about 30 to about 46 minutes and disk usage from 33 GB to 58 GB. I could not confirm from the patch tracker whether this series has been merged, so treat it as the best public estimate of cost and as a statement of direction, not of shipped behavior.

Those figures come from one vendor’s test environment and will differ with your hardware, but the shape is useful. A full-kernel Rust build roughly adds half again to the wall-clock time and nearly doubles the build tree. Here is an illustrative calculation (the inputs are the cover-letter figures; the CI fleet is hypothetical). A team running 40 kernel builds per working day sees 40 x 16 extra minutes, about 10.7 extra build-hours daily, before caching. With sstate and ccache hit rates in the 70 to 90 percent range the marginal cost shrinks substantially, but the disk number matters for ephemeral CI runners, which often have a fixed volume size. The conclusion is not that Rust is expensive; it is that the first Rust-enabled pipeline will fail on a disk-quota or timeout setting you did not think to raise.

Buildroot is a similar story at smaller scale: it must provide a host Rust toolchain and bindgen, and its minimal-image philosophy fights the size of a kernel-source-plus-rust-src tree. I did not find an official Buildroot statement for kernel Rust support during research, so I make no claim about its current state; check the version you use.

An illustrative driver skeleton

The following is a sketch of the shape of a Rust platform driver for an imaginary memory-mapped sensor. It is illustrative only: the kernel’s Rust APIs change from release to release (the abstractions are still evolving), and this code has not been compiled against a specific tree. Use the in-tree samples/rust directory for the version you target.

// ILLUSTRATIVE ONLY: API names and signatures move between kernel releases.
use kernel::{c_str, device::Core, of, platform, prelude::*};

struct DemoSensor {
    // Owned resources: dropped, and therefore released, with the driver.
    // regs: IoMem, irq: IrqRegistration, ...
}

kernel::of_device_table!(
    OF_TABLE,
    MODULE_OF_TABLE,
    <DemoSensor as platform::Driver>::IdInfo,
    [(of::DeviceId::new(c_str!("vendor,demo-sensor")), ())]
);

impl platform::Driver for DemoSensor {
    type IdInfo = ();
    const OF_ID_TABLE: Option<of::IdTable<Self::IdInfo>> = Some(&OF_TABLE);

    fn probe(
        pdev: &platform::Device<Core>,
        _info: Option<&Self::IdInfo>,
    ) -> Result<Pin<KBox<Self>>> {
        dev_info!(pdev.as_ref(), "probing demo sensor\n");
        // Map registers, request IRQ, read chip id. Each step returns Result;
        // on failure, `?` returns and everything acquired so far is released.
        KBox::new(DemoSensor {}, GFP_KERNEL)?.into()
    }
}

kernel::module_platform_driver! {
    type: DemoSensor,
    name: "demo_sensor",
    authors: ["Example Author"],
    description: "Illustrative Rust platform driver",
    license: "GPL",
}

Three things are worth noticing even though the exact spelling will drift. The driver declares its device-tree match table through a macro rather than a hand-assembled C array. The probe function returns a Result, so there is no goto-based cleanup ladder. And there is no unsafe anywhere; every register access in a real version would go through an abstraction that checks bounds against the mapped region.

The out-of-tree driver problem

Most IoT products do not ship upstream drivers. They ship a vendor kernel, often years behind mainline, with SoC vendor drivers for the radio, the camera pipeline, the NPU and the secure element carried as patches or out-of-tree modules. That is where the memory-safety risk concentrates, because those drivers are written once, under schedule pressure, rarely reviewed by subsystem maintainers, and almost never updated.

Rust does not fix that by itself, and it creates a new tension. Rust abstractions are in-tree and have no stable internal interface guarantee, the same as C’s in-kernel API. A Rust out-of-tree module compiles against the exact abstraction set of the kernel it is built with. A vendor on an LTS kernel therefore sees only the abstractions that existed when that branch was cut, and anything newer cannot be assumed. The practical effect is that Rust driver work is easiest on a recent kernel and gets harder the older your vendor tree is.

That connects to supply-chain policy, because a Rust-capable BSP needs a kernel recent enough to host the abstractions you need. For a deeper look at how kernel-level instrumentation interacts with the same pinned-kernel constraint, see our analysis of eBPF for kernel tracing and observability.

Where Rust drivers pay off first

Based on the in-tree record, the sensible early targets share three properties: a self-contained protocol or algorithm, resource-lifetime complexity, and narrow interaction with core kernel structures.

• Parsing-heavy leaf drivers. A driver that decodes a vendor wire protocol from a radio or fieldbus controller is the classic memory-safety hazard, and Rust’s bounds-checked slices remove a whole class of bug.
• Resource-ownership-heavy drivers. Anything juggling clocks, regulators, IRQs and DMA across probe and remove, with many error paths, benefits from destructor-based cleanup.
• Security-critical IPC and mediation layers. Binder is the existence proof: an attack-surface-dense component rewritten in Rust and merged.

Pure register-banging drivers for simple peripherals gain less, because C code for them is short and the risk is low. The effort-to-benefit ratio is worst for small drivers on an old vendor kernel with no abstractions available.

Decision matrix for new driver work

The table compares four strategies across the criteria that usually decide the choice. The ratings are my judgment from the evidence above, not measured data.

Strategy	Memory-safety gain	Kernel version needed	Toolchain burden	Maintenance risk	Best fit
C driver, out of tree	None beyond review and static analysis	Any	Low	High on every kernel bump	Legacy BSPs, simple peripherals
Rust driver, upstream first	High, plus maintainer review	Current mainline	Medium to high	Low, upstream carries it	New silicon, new peripherals
Rust driver, out of tree	High in driver code	Recent kernel with needed abstractions	High, needs rustc, bindgen, clang	High, abstractions drift	Vendor driver with security exposure
C driver plus Rust user-space daemon	Partial, protocol parsing moves to user space	Any	Low in kernel, normal in user space	Medium	Old kernels, parsing-heavy protocols

Figure 4: Decision flow for new driver work. The first gate is whether the subsystem has Rust abstractions; the second is whether your pinned kernel and toolchain can host them.

The flow works from the cheapest question to the most expensive. If the subsystem you need, for example a particular bus or media framework, has no Rust abstractions in your kernel, you cannot write a Rust driver for it no matter how much you want to. If it does and your pinned LTS and toolchain cannot host them, the fallback is moving the risky logic, protocol parsing in particular, into a memory-safe user-space process, an approach that also aligns with the process-isolation guidance in our industrial zero-trust architecture article. Only the Rust-in-kernel branch with a viable upstream path avoids the long-term maintenance cost of out-of-tree abstraction drift.

A worked risk estimate for a fleet (illustrative)

Why bother, if the memory-safety share is a statistic about the whole kernel rather than your driver? Consider a hypothetical fleet of 50,000 gateways running a vendor kernel with 12 out-of-tree drivers, none of which will receive upstream review. Suppose, purely for illustration, that the team’s own audit finds 30 percent of historical bug fixes in those drivers were memory-safety bugs, and that each field-exploitable bug costs an over-the-air patch cycle of two engineer-weeks plus a staged rollout. Even if Rust only prevented half of that class in newly written drivers, the saving scales with the number of new drivers and the cost of a field patch, not with fleet size alone. The important input is the second one: for devices behind customer firewalls that update twice a year, the cost of a single exploitable bug is much higher than the engineer-week figure suggests. These numbers are invented to show the structure of the argument. Replace them with your own defect history before using the calculation to justify anything.

The structural lesson is that the payoff of Rust is largest where the cost per defect is largest: drivers that handle untrusted external input (radios, USB gadgets, fieldbus controllers, camera ISPs fed by user-controlled firmware) on devices that are expensive to patch. Drivers that handle only trusted on-board peripherals gain far less.

The upstreaming gradient

There is a policy dimension to this too. The DRM maintainer Dave Airlie told the summit that the graphics subsystem is about a year from disallowing new C drivers and requiring Rust, and that dependencies in core kernel code were more like one to two years away. This is a statement by one maintainer about one subsystem, not a kernel-wide rule, and timelines of that kind slip. But it indicates a direction: in some subsystems, new drivers will eventually be accepted only in Rust, which means a vendor who wants a driver accepted upstream may need Rust skills regardless of strategy. The upstreaming gradient therefore tilts toward Rust for new silicon, while existing C drivers remain supported for the long term.

Trade-offs, Gotchas, and What Goes Wrong

Rust in the kernel is a real improvement, but several failure modes are specific enough to name.

Unsafe is concentrated, not eliminated. The abstraction layer still contains unsafe blocks, and a mistake there poisons every driver that uses it. The benefit is that a few hundred reviewed lines replace thousands of unreviewed ones, but a bug in a widely used abstraction has a larger blast radius than a bug in one C driver. Treat abstraction updates in your kernel tree as security-relevant changes.

The API is not stable. The kernel has never promised a stable internal API, and the Rust layer is younger and moves faster. An out-of-tree Rust module written for 6.18 may need rewriting for 7.1, and the abstractions are still being designed. Budget maintenance time for each kernel bump, and use the samples/rust examples from the exact tree you build against.

Toolchain drift is a project risk. The minimum jumped from 1.78.0 to 1.85.0 between the 6.18 series and 7.1, bringing a new bindgen floor with it (0.65.1 to 0.71.1 in the patch series that made the change). A product pinned to a kernel branch must also pin the Rust toolchain, record it in the build manifest, and rebuild reproducibly. A Yocto layer that quietly upgrades rustc can break a kernel build that passed last week.

Build-time and disk cost are real. The Yocto cover-letter figures, about 30 to 46 minutes and 33 GB to 58 GB, are one data point, but plan for CI timeouts and ephemeral-runner disk limits before the first Rust build.

Reviewer scarcity is a bottleneck. Laurent Pinchart, the Video4Linux maintainer, voiced a concern reported in coverage of the debate: maintainers cannot “stop everything and learn Rust anytime soon.” Rust patches need reviewers who understand both the C invariants and the Rust abstraction, and that population is small. Expect slower review for Rust code in subsystems whose maintainers are not yet fluent, and expect friction when a C-side change breaks Rust bindings.

Safety is not correctness. Rust eliminates memory-safety bugs in safe code. It does not prevent logic errors, deadlocks, incorrect register sequences, bad power-management ordering, or a driver that misreads a datasheet. A common anti-pattern is treating “written in Rust” as a security audit and skipping fuzzing and hardware-in-the-loop testing.

Architecture and endianness holes. The supported list excludes 32-bit RISC-V, MIPS and big-endian ARM, and s390 support carried open questions in the summit discussion. If your fleet has any such silicon, the Rust path is closed for that kernel.

Spec and compiler risk. The Rust language still lacks a complete formal specification, which the summit coverage flagged as a concern, and functional-safety certification regimes want one. If you sell into IEC 61508 or ISO 26262 contexts, expect questions you cannot yet answer from the language side alone. I did not find an authoritative position on certifying kernel Rust code, so treat that as an open item.

The thread tying these together is that Rust moves risk from runtime to build time and review time. That is a good trade for most teams, but only if the build and review capacity exist.

Practical Recommendations

For most embedded and IoT teams, the right posture in 2026 is to prepare the platform now and write Rust drivers selectively, starting with the code that parses untrusted input.

First, make the toolchain a first-class pinned dependency. Record rustc, bindgen and libclang versions alongside the kernel version in your manifest, and reproduce them in CI. Second, run a trial Rust-enabled build of your kernel branch in a non-blocking pipeline now, so the disk, timeout and caching issues surface before anyone depends on it. Third, audit your out-of-tree drivers by exposure: those that handle untrusted external input and live on hard-to-patch devices are the first rewrite or isolation candidates. Fourth, pick your path per driver using the decision flow in Figure 4, defaulting to upstream-first for new silicon and to user-space isolation where your kernel is too old.

On skills, send one or two kernel engineers through the in-tree samples/rust examples and the abstraction documentation before you need them, and take a first driver that is small, self-contained and fuzzable. Avoid starting with a driver that spans subsystems whose abstractions are still immature. For the Linux-class gateways in your estate, also revisit the architecture in our IIoT edge gateway architecture guide, since the kernel is only one layer of the gateway’s attack surface.

Adoption checklist

• [ ] Kernel branch, rustc, bindgen and libclang versions pinned and recorded together
• [ ] Rust-enabled trial build running in non-blocking CI, with disk and timeout headroom raised
• [ ] Target architectures checked against the kernel’s Rust support table
• [ ] Out-of-tree drivers ranked by exposure to untrusted input and patchability
• [ ] Decision flow applied per driver: upstream, out of tree, or user-space isolation
• [ ] Abstraction availability confirmed in your exact kernel tree before committing to Rust
• [ ] Fuzzing and hardware-in-the-loop tests in place regardless of language
• [ ] One engineer assigned to track Rust for Linux release notes each kernel cycle

Frequently Asked Questions

Is Rust still experimental in the Linux kernel?

No. At the 2025 Linux Kernel Maintainers Summit in Tokyo, developers agreed the Rust experiment was concluded, and Miguel Ojeda posted a patch on 12 December 2025 removing the “Rust experiment” section from the documentation. Coverage of the 7.0 release reports the experimental label as gone. In practice this means Rust is a supported, permanent part of the kernel, though most of the tree remains C and many subsystems still lack Rust abstractions.

Which Linux kernel version added Rust support?

Rust support was merged into mainline in Linux 6.1, as a trial to see whether the language suited the kernel. The first drivers of consequence came later: the Rust QR-code panic screen, Android’s ashmem on the 6.12 kernel, and the binder driver, merged for 6.18-rc1. Rust is optional at build time, enabled with CONFIG_RUST, so a kernel built without it behaves exactly as before and needs no Rust toolchain.

What Rust version does the Linux kernel require?

The kernel’s minimum-versions documentation lists Rust 1.85.0 and bindgen 0.71.1, both needed only if Rust support is enabled. The project follows Debian Stable’s Rust version as its floor, adopting each bump some months after Debian releases. The floor was 1.78.0 from Linux 6.11 and moved to 1.85.0 in 7.1, though the 6.18 stable series keeps 1.78.0. Always check the documentation of the exact kernel you build.

Can I write a Linux driver in Rust today?

Yes, if your kernel has Rust abstractions for the subsystem you need. Platform and PCI-style drivers have in-tree examples, and the kernel ships Rust samples under samples/rust. Subsystems without abstractions force you to write C or add the abstractions yourself. The internal API is not stable, so a driver written for one release may need changes for the next. Verify against your exact tree and treat any example as a starting point.

Does Rust make Linux drivers completely secure?

No. Rust removes the memory-safety bugs, use-after-free, out-of-bounds access and many data races, in safe code. It does not prevent logic errors, protocol mistakes, deadlocks or hardware misuse, and the abstraction layer still contains reviewed unsafe code. Kernel developers report that Rust drivers have been safer in practice, and LWN noted no CVEs assigned to Rust code at the time, but that reflects a young, small code base rather than a guarantee.

What does Rust in the kernel mean for Yocto and Buildroot builds?

Your build must provide rustc, the Rust standard library sources, bindgen and clang with libclang. A Wind River patch series for Yocto’s linux-yocto adds exactly this and reports build time rising from about 30 to 46 minutes and disk use from 33 GB to 58 GB in its test setup. Check whether your Yocto or Buildroot release supports kernel Rust before planning, because support and cost vary by version.

Further Reading

• Rust for no_std firmware on microcontrollers: the bare-metal counterpart to this article
• eBPF observability and kernel tracing: another kernel-extension technology with its own safety model
• DuckDB versus ClickHouse for embedded analytics: an architecture decision record on another embedded-stack choice
• GPU kernel engineering and data starvation: a related look at where driver and kernel-level performance bottlenecks hide
• Rust for Linux project site: the project’s version policy and status pages
• Linux kernel Rust documentation: quick-start, architecture support and coding guidelines

References

1. LWN.net, “The (successful) end of the kernel Rust experiment,” December 2025. https://lwn.net/Articles/1049831/
2. LWN.net, “The state of the kernel Rust experiment,” December 2025. https://lwn.net/Articles/1050174/
3. Miguel Ojeda, “[PATCH] rust: conclude the Rust experiment,” linux-kernel mailing list, 12 December 2025. https://lkml.iu.edu/hypermail/linux/kernel/2512.1/06411.html
4. Phoronix, “New Linux Patch Confirms: Rust Experiment Is Done, Rust Is Here To Stay,” December 2025. https://www.phoronix.com/news/Rust-To-Stay-Linux-Kernel
5. The New Stack, “Rust Goes Mainstream in the Linux Kernel.” https://thenewstack.io/rust-goes-mainstream-in-the-linux-kernel/
6. DevClass, “Rust boosted by permanent adoption for Linux kernel code,” 15 December 2025. https://devclass.com/2025/12/15/rust-boosted-by-permanent-adoption-for-linux-kernel-code/
7. Linux Magazine, “Kernel 7.0 Is a Bit More Rusty.” https://www.linux-magazine.com/Online/News/Kernel-7.0-Is-a-Bit-More-Rusty
8. Rust for Linux, “Rust version policy.” https://rust-for-linux.com/rust-version-policy
9. Linux kernel documentation, “Minimal requirements to compile the kernel.” https://docs.kernel.org/process/changes.html
10. Linux kernel documentation, “Quick Start” and “Arch Support” for Rust. https://docs.kernel.org/rust/quick-start.html and https://docs.kernel.org/rust/arch-support.html
11. Rust for Linux, “Android Binder Driver.” https://rust-for-linux.com/android-binder-driver
12. Phoronix, “Tyr Driver Being Submitted For Linux 6.18 As Rust-Based Arm Mali Driver.” https://www.phoronix.com/news/Rust-DRM-Drivers-Linux-6.18-Tyr
13. Jocelyn Falempe, “[PATCH v2 0/4] drm/panic: Add a qr_code panic screen,” July 2024. https://lkml.iu.edu/hypermail/linux/kernel/2407.1/01611.html
14. Harish Sadineni et al., Rust support for linux-yocto, OE-Core patch series, January 2026. https://patchwork.yoctoproject.org/project/oe-core/cover/20260129163910.2612040-1-Harish.Sadineni@windriver.com
15. “[PATCH v2 00/33] rust: bump minimum Rust and bindgen versions,” linux-doc, April 2026. https://ratatoskr.run/linux-doc/2026/04/3499753/t

By Riju – about