Rust Is Now Official in the Linux Kernel — and Memory Safety Is Becoming Security Policy

The most consequential security improvement in computing history might not be a new authentication scheme, a smarter firewall, or a better detection system. It might be changing the programming language that operating systems are written in.

Memory safety vulnerabilities — use-after-free bugs, buffer overflows, null pointer dereferences, integer overflows that become buffer overflows — have accounted for approximately 70% of Microsoft's high-severity CVEs for years. Google reports similar figures for Chrome and Android. The NSA has published guidance stating that about 70% of all exploitable software vulnerabilities are memory-safety issues. These aren't obscure edge cases — they're the most common class of exploitable vulnerability, and they've been common for forty years because most operating system code is written in C and C++, languages that make it easy to write memory-unsafe code and hard to detect the bugs until something crashes in production.

Rust eliminates the entire category. Not by adding a runtime garbage collector — Go and Java take that approach, and it costs performance that operating systems can't afford. Instead, Rust uses a compile-time borrow checker that tracks ownership and lifetimes of every piece of memory at build time. If you write code that could produce a use-after-free bug, the Rust compiler refuses to compile it. The memory error doesn't happen at runtime. It fails at build time with an error message telling you exactly what's wrong. No crash, no CVE, no patch cycle, no emergency hotfix shipped at 3 AM.

The Linux Kernel Milestone

The Linux kernel is the foundation of Android, most cloud infrastructure, and a vast range of embedded systems. It's also written almost entirely in C — roughly 27 million lines accumulated over thirty years. Adding a new programming language to a codebase this old and this critical is a decision that takes years of validation before it becomes official policy.

The first Rust code was merged into the Linux kernel with the 6.8 release in December 2023. The initial implementations covered the Asahi GPU driver (supporting Apple M1 and M2 Macs running Linux) and some NVMe driver infrastructure — areas where new development was happening and where the risk of breaking existing functionality was minimized. This was a proof of concept that Rust could operate within the kernel's stringent constraints and coexist with the existing C codebase.

In December 2025, the Linux kernel project officially declared Rust in the kernel no longer experimental. Rust kernel development is now an official part of the kernel development process, with the same stability guarantees, testing requirements, and code review standards as C development. New kernel subsystems can be written in Rust with confidence that Rust will remain a supported kernel language for the long term — a commitment that previously couldn't be made because the experimental designation meant the Rust kernel infrastructure could be removed if it didn't work out.

This matters practically for several reasons. Driver developers can write new drivers in Rust without uncertainty about whether the Rust kernel infrastructure will exist in the next kernel version. Security-critical kernel components — network stacks, filesystem drivers, cryptographic subsystems — can be systematically rewritten in Rust over time, reducing the attack surface of code that currently runs with ring-0 privileges and processes untrusted external input. And it signals to the broader systems programming community that Rust is a serious long-term choice for kernel work, which affects hiring, training, and tool investment decisions across the industry.

Android's Rust Adoption and Results

Google began adding Rust to Android in 2021 and has been the most transparent about measuring the results. By 2024, Google reported that approximately 77% of new Android code is written in Rust — a figure reflecting new code being added to the platform, not the existing C and C++ codebase, which remains largely as written and continues to be maintained.

The measurable security impact is significant. The rate of memory safety vulnerabilities discovered in Android has declined year-over-year since 2019, the same period during which Rust adoption began. Google attributes this directly to language choice: Rust code running in Android doesn't produce memory safety CVEs at the same rate as C code, because the compiler prevents the entire class of bugs before the code ships.

Android's Bluetooth stack, portions of the network stack, and components of the media codec infrastructure have been rewritten in Rust. These are exactly the attack surfaces that have historically produced high-severity vulnerabilities — they process untrusted external input (Bluetooth pairing packets, network data, video files from untrusted sources) with complex parsing logic where a single off-by-one error can become a remote code execution vulnerability exploitable without user interaction.

Microsoft's Approach

Microsoft's adoption of memory-safe languages is distributed across several initiatives rather than a single centralized mandate. The Windows kernel team has been evaluating Rust for new kernel driver development, and Microsoft contributes actively to the Rust for Windows project that provides Rust bindings to Windows APIs. Azure infrastructure has adopted Rust in several components. Microsoft's Hyperlight project — a lightweight hypervisor designed for running serverless functions at scale — was built in Rust from the ground up.

More broadly, Microsoft has committed to writing new security-critical code in memory-safe languages (which includes Rust, Go, and C# alongside the older safe languages Swift and Java) and systematically rewriting existing C and C++ code in memory-safe alternatives where the security risk justifies the engineering cost. This is not a "rewrite everything in Rust" mandate — it's a risk-prioritized approach that focuses memory-safe rewrites on code that handles external input and runs with elevated privileges, which is exactly where memory bugs translate into exploitable vulnerabilities.

The Real Challenges

Rust's memory safety guarantees come with genuine tradeoffs that matter for real-world adoption:

The learning curve is steep. The borrow checker enforces ownership rules that feel unfamiliar to developers coming from C, C++, or most other languages. "Fighting the borrow checker" is a common frustration for developers new to Rust. Google estimates it takes six months to a year for an experienced C developer to become genuinely productive in Rust on a large codebase. At scale, this is a significant training and recruitment investment.

Interoperability with C is necessary but complex. Any realistic migration strategy involves Rust calling C and C calling Rust — crossing the FFI boundary between the two languages. That boundary requires unsafe Rust blocks, which can introduce the same memory bugs Rust prevents. Getting FFI boundaries right requires careful engineering, and every unsafe block needs careful review.

Compile times are longer. The borrow checker's analysis is computationally expensive. Large Rust codebases compile significantly slower than equivalent C codebases, which affects developer iteration speed and CI/CD pipeline times. This is a known issue the Rust team is actively working on, but it remains a real cost.

The existing codebase isn't going anywhere quickly. The Linux kernel is 27 million lines of C. Moving this incrementally to Rust will take many years, and the existing C code will continue producing memory safety vulnerabilities throughout that transition. The shift to memory-safe languages is structural and generational — it prevents new vulnerabilities in new code, not existing bugs in existing code.

The Policy Dimension

The most significant recent development isn't a technical milestone — it's the shift from technical recommendation to security policy. CISA, the NSA, and their Five Eyes equivalents have all published formal guidance stating that software developers have a responsibility to use memory-safe languages for new security-critical code. The White House National Cybersecurity Strategy references memory safety explicitly. This framing changes the equation for organizations writing software that handles sensitive data or critical infrastructure.

It's no longer purely a technical decision. It's a question of whether an organization can defend its language choices to regulators, auditors, and customers. The combination of technical maturity — Rust's tooling, ecosystem, and documentation have improved dramatically since 2021 — and formal policy pressure is accelerating adoption beyond what the technical case alone would drive.

Memory safety is a solved problem in programming language theory. Making it the practical default in operating system infrastructure is a generational engineering project. The Linux kernel milestone, Android's adoption metrics, and the policy shift all indicate that project has moved from academic exercise to engineering reality — slowly, with rough edges, and on a timescale measured in decades rather than product cycles. The direction is clear, and the momentum is real.