In 2022, after years of technical debate, Rust support was merged into the Linux kernel —Version 6.1 was the first release with the new infrastructure. This was not a rejection of C, nor an attempt to rewrite the kernel. C remains the foundation. What changed was the recognition that the kernel's security risks stemmed not from its core, but from the vast and growing perimeter code. This code is often written not by kernel maintainers but by vendors and other outsiders under real-world constraints such as tight deadlines, limited testing, hardware variability, and the need to maintain broad compatibility. Addressing these vulnerabilities requires a strategy that strengthens the periphery without destabilizing the millions of lines of existing, functional core code."
The kernel's memory management problem is due to a hard constraint: deterministic performance. The CPU must respond to hardware interrupts with microsecond precision. Using a garbage collector (GC) as a solution is not possible. A GC's "Stop-the-World" pauses, while acceptable in userspace, would be catastrophic in the kernel, resulting in dropped packets, missed deadlines, and system failure. Consequently, the kernel relies on manual management via kmalloc, kfree, and careful reference counting, placing the burden of memory safety entirely on the programmer.
This manual system doesn't tend to fail in the core - the allocators, SLUB/SLAB, and VM layer are centralized, heavily audited, and maintained by specialists. The flaws are happening in the perimeter code. Device drivers, networking stacks, and filesystems are sprawling, hardware-specific, and often vendor-contributed. In C, the compiler cannot catch pointers freed too early, freed twice, or shared unsafely across interrupts and callbacks.
Rust addresses this by moving enforcement from human discipline to compile-time checks. Through ownership, borrowing, and lifetimes, Rust ensures memory safety before execution—without garbage collection pauses. The ownership system itself adds no runtime overhead, though kernel integration requires FFI shims and panic handling that do add modest cost. Safe Rust provides strong guarantees against use-after-free, double-free, and data races, though it does not prevent logic errors or bugs in necessarily unsafe code blocks.
The kernel community is taking a surgical approach: Rust for new device drivers and peripheral abstractions, C for core subsystems. This hybrid model avoids rewriting millions of lines of functional code while addressing where vulnerabilities are occurring.
The transition is creating genuine friction — reviewers now need expertise writing and debugging in two languages. The compromise of using both Rust and C in the kernel is working. But balancing the two, as well as the differing mindsets and habits of programmers accustomed to each language — that's one of the main challenges in the ongoing evolution of what is arguably the world's most important operating system."
Ben Santora - February 2026
Top comments (3)
Rust proponents have always had the option simply to fork the entire kernel and rewrite as much of it in Rust as they want — yet they don't do that for some reason.
Right, in theory, anyone can fork Linux and rewrite it in Rust, but 40 million lines of code? I think the Rust work being done is about incrementally improving safety in new and high-risk code without breaking what already works.
Forking Linux and incrementally improving safety in new and high-risk code without breaking what already works aren't mutually exclusive.
The benefit of forking is that those people who don't care about Rust and don't want to learn rust can simply ignore it completely since there won't be any in their kernel and won't feel like Rust is being shoved down their throats.
Those people interested in Rust can incrementally rewrite C code in their forked kernel into Rust code at their own pace. From the point of view of the Rust developers, it's no different that working on the mainline kernel except they don't have to argue with the C purists.
Win-win.