Greg Kroah-Hartman dropped a bombshell at RustWeek 2026 in Utrecht this week. His presentation outlined a Rust-based proposal still deep in development, one that could potentially wipe out around 80% of the Common Vulnerabilities and Exposures (CVEs) the Linux kernel generates. Let that sink in. This isn’t some speculative paper; it’s a claim from an individual who’s personally scrutinized every kernel security bug since the Linux kernel security team’s inception in 2005.
The Unseen Achilles’ Heel of C
The bedrock of the problem, as Kroah-Hartman articulated, lies in how C handles untrusted data. Any data ingress from user space or hardware should, by rights, be met with extreme suspicion. C, however, offers no strong compile-time mechanisms to enforce this. Once data crosses the boundary into the kernel, it sheds its provenance, transforming into a generic pointer. This loss of context means that crucial checks, meant to prevent exploits, often fall by the wayside as the data propagates. The kernel’s foundational design assumed hardware was inherently trustworthy—a premise increasingly strained by the rise of sophisticated, potentially malicious hardware.
Rust’s Immediate Wins in the Kernel
Even before this sweeping proposal takes shape, Rust is already a quiet force for good within the kernel. Simple, yet insidious, bugs like the failure to check error return values and the oversight of releasing locks are significant contributors to kernel CVEs. Rust’s strong type system and ownership model catch both of these at compile time. Kroah-Hartman estimates that these two fixes alone address a staggering 60% of kernel bugs. Furthermore, the necessity of writing Rust bindings for existing C code has inadvertently pressured kernel maintainers. It’s forcing them to meticulously document and re-evaluate their APIs, clarifying ownership semantics, lock disciplines, and const-correctness—a welcome side-effect of embracing a new language.
The ‘Untrusted’ Sentinel
At the heart of Kroah-Hartman’s forward-looking vision is a novel Rust type: Untrusted<T>. Developed in collaboration with kernel contributor Benno Lossin, this type acts as a compile-time marker for data originating from user space or hardware. Crucially, it carries no runtime overhead. Accessing the underlying data necessitates an explicit validation step, converting it from untrusted to trusted. This architectural shift centralizes all validation logic into a single, easily auditable location.
For the average Linux user, the implications are profound. A substantial fraction of the CVEs currently trickling down to distributions as security patches would simply cease to exist before they ever become a threat.
But here’s the vital caveat: this isn’t merged code. Significant modifications are still required in the Rust compiler itself, and parallel efforts on field projections are ongoing. Kroah-Hartman concluded his presentation with a direct appeal for more Rust kernel developers, pointing interested parties toward the Rust for Linux mailing list as the official starting point.
Why Does This Matter for Developers?
The potential reduction in CVEs by 80% is not just a security win; it’s a fundamental shift in the developer experience for the Linux kernel. Imagine a codebase where entire classes of memory-related vulnerabilities are simply impossible to introduce. This reduces the cognitive load on kernel developers, allowing them to focus on features and performance rather than constantly battling the inherent footguns of C. The Untrusted<T> type, in particular, represents a sophisticated abstraction that enforces security policies at the type level, rather than relying on runtime checks or developer discipline alone. This pattern could well influence how security-sensitive code is written across other domains, not just operating system kernels.
What About the Transition Costs?
The specter of introducing a new language into the Linux kernel, a project built over decades in C, is not trivial. Kroah-Hartman acknowledged this implicitly by stressing the ongoing development and the need for more contributors. The Rust for Linux initiative is a long game. It’s not about replacing C overnight—that’s a non-starter. Instead, it’s about carefully introducing Rust into new subsystems and gradually modernizing critical areas. The associated costs involve developer training, tooling integration, and establishing strong review processes for Rust code within the kernel community. However, the potential long-term savings in security patching and bug hunting could vastly outweigh these initial investments. This is precisely why the data point of 80% is so compelling; it suggests a return on investment that’s hard to ignore.
The Long Road to 80%
While the promise of an 80% CVE reduction is electrifying, it’s essential to maintain a data-driven perspective. Kroah-Hartman’s estimate is based on his deep experience with kernel vulnerabilities. The two primary fixes—handling error returns and managing locks—already account for a significant portion. The Untrusted<T> type aims to capture the remainder stemming from input validation. However, achieving this high percentage will require widespread adoption and careful implementation across the kernel. It also depends on the Rust language itself and its ecosystem continuing to mature in ways that support the demanding requirements of kernel development. The journey will undoubtedly be incremental, marked by phases of adoption, refinement, and ongoing developer engagement.
Greg Kroah-Hartman estimates those two fixes alone cover around 60% of kernel bugs.
The path forward involves not just technical implementation but also community building. The call for more Rust kernel developers is genuine; this isn’t a solo effort. The mailing list is the nexus for this nascent community, and its growth will be a key indicator of the proposal’s ultimate success. The potential here is immense, offering a glimpse into a future Linux kernel that is inherently more secure by design.
🧬 Related Insights
- Read more: Open Source Stewardship Beats Dependency Management—Here’s Why Bloomberg’s Betting Big
- Read more: Is Your Productivity App Just Another Distraction?
Frequently Asked Questions
What is the main benefit of using Rust in the Linux kernel? Rust’s memory safety guarantees and strong type system help prevent entire classes of bugs, like buffer overflows and use-after-free errors, that are common in C. This leads to more secure code and fewer vulnerabilities.
How will the ‘Untrusted’ type improve kernel security?
The Untrusted<T> type acts as a compile-time marker for data from external sources. It enforces explicit validation before the data can be used, centralizing security checks and preventing the accidental misuse of untrusted input.
Will Rust replace C entirely in the Linux kernel? No, the current focus is on introducing Rust into new subsystems and carefully modernizing existing ones. C will likely remain the primary language for the foreseeable future, with Rust serving as a complementary, safer alternative for specific areas.
