The Linux kernel is one of the most security-critical codebases in the world, and it is written almost entirely in C — a language that trusts the programmer completely and offers no protection against buffer overflows, use-after-free bugs or data races. Those error classes account for the majority of serious vulnerabilities in C codebases, a pattern documented repeatedly across the industry.

Rust changes the calculus by making the entire class of memory-safety bugs unrepresentable in safe code. Kernel support — initial merged in 2022 after years of community work — has progressed through the predictable lifecycle: experimental, contested, then increasingly normal.

Why it matters

The security argument alone justifies the effort, but the adoption logic is economic. New kernel code gets written constantly — drivers, filesystems, networking features — and each new line of C carries the historical defect rate. Rust offers a path where new code simply doesn't carry the dominant vulnerability class.

Institutional backing has been decisive. Google uses Rust in Android's kernel components and has reported measurable vulnerability reductions in memory-unsafe code rewritten in Rust; Microsoft has endorsed the approach for Windows kernel work; CISA and international security agencies have published guidance urging memory-safe languages for critical infrastructure.

How adoption actually proceeds

Rust code in the kernel coexists with C through carefully maintained interface layers. New drivers are the natural entry point — self-contained, peripherally important, and written fresh rather than ported. Filesystems and deeper subsystems follow as abstractions mature and maintainer confidence builds.

The human factors are the real constraint. Kernel maintainers are experts in C and Unix tradition; Rust adds a language, a toolchain and a review burden. Contentious public debates — including a high-profile maintainer resignation over Rust integration policy — have marked the process. Progress has continued through it: each major kernel release brings more Rust code and more subsystems accepting it.

Evidence

Mainline kernel releases now include Rust-written drivers for networking, storage and GPU support, with the abstraction layer (the Rust bindings to kernel APIs) growing release by release. Vendor commitments — Google's Android and Chromium efforts, Microsoft's Windows kernel statements, SUSE's and Red Hat's distribution support for Rust toolchains — provide the commercial grounding.

The measured security results are early but consistent with language-level expectations: Google's reports of reduced memory-safety vulnerabilities in rewritten components, and industry-wide data showing Rust codebases exhibit dramatically lower rates of the vulnerability classes that dominate CVE statistics.

The competing read

Longtime kernel developers argue the C codebase's maturity — decades of hardening, tooling and review culture — already manages memory-safety risk better than raw defect statistics suggest, and that Rust adds toolchain complexity and a two-language maintenance burden to a system whose stability is a civilizational asset.

The rebuttal is empirical: the defect rates in new C code remain what they have always been, and the industry's largest software producers have concluded the trade is worth it. The kernel community's own trajectory — Rust code merging, subsystems opting in, toolchain maturing — is the strongest evidence of where the argument has landed.

What happens next

Watch for the first significant subsystem (rather than driver) to adopt Rust for new development, watch the toolchain stabilization work that lets distributions ship kernel Rust support without bespoke compilers, and watch the broader ecosystem — FreeBSD, Windows drivers, embedded systems — where the same pattern is beginning. The C kernel isn't going anywhere. The question is what gets written next.