Rust Could Eliminate 80% of Linux Kernel CVEs?

Rust Could Eliminate 80% of Linux Kernel CVEs?

Linux stable maintainers are pinning their hopes on a new Rust type system construct to address a category of bugs that the C language has never fully avoided — and the numbers behind the proposal are striking.

This week at RustWeek 2026 in Utrecht, Netherlands, Greg Kroah-Hartman — Linux Foundation Fellow and stable kernel maintainer — presented a Rust-based proposal still under development that could eliminate approximately 80% of CVEs generated by the Linux kernel. The event, organised by RustNL, ran from May 18–23 and featured talks, workshops, and the Rust All Hands.

What Is a CVE?

CVE stands for Common Vulnerabilities and Exposures — a publicly maintained list of disclosed computer security flaws. When a security researcher or vendor refers to a CVE, they are referencing a specific flaw that has been assigned a unique CVE ID for tracking and remediation. These flaws can range from minor information disclosures to critical remote code execution vulnerabilities.

The weight of Kroah-Hartman’s claim comes from his unique vantage point: he has personally reviewed every kernel security vulnerability since the Linux kernel security team was established in 2005, making him one of the most qualified people on Earth to estimate the scope of the problem.

The Blind Spot of C

The core problem, as Kroah-Hartman sees it, is untrusted data. Every time data arrives from user space or from hardware, the kernel should treat it with suspicion. The C programming language has never had a reliable way to enforce this discipline at the language level.

Once data is copied from user space into the kernel in C, it becomes a regular pointer — it loses all contextual information about its origin. It can then be passed around freely, and the external checkers that should be catching the problem do not always get run. Hardware presents an additional layer of the same problem: the kernel’s design historically assumes hardware trustworthiness, an assumption increasingly difficult to uphold as malicious hardware becomes a genuine threat vector.

What Rust Already Fixes — Before the New Proposal

Even before the new proposal ships, Rust is already making a measurable difference inside the kernel. Two of the most significant contributors to kernel CVEs are:

• Failing to check error return values — a classic C pitfall where an unchecked error silently propagates into unsafe state.
• Forgetting to release locks — which can cause deadlocks, use-after-free, and other memory safety violations.

Rust handles both of these issues at compile time, before code ever runs. Kroah-Hartman estimates that these two fixes alone will resolve approximately 60% of kernel bugs.

Beyond that, writing Rust bindings for existing C kernel code has quietly pushed kernel maintainers to genuinely document and reason through their APIs — working out ownership semantics, lock rules, and const-correctness in ways C never demanded.

Introducing the Untrusted<T> Type

Kroah-Hartman’s proposed solution is a new Rust type called Untrusted<T>, developed in collaboration with kernel contributor Benno Lossin. The type attaches to data arriving from user space or hardware as a compile-time marker, incurring zero runtime overhead.

The key constraint is that developers cannot access the underlying data without going through an explicit validation step that converts it from untrusted to trusted. This pushes all verification code into a single, visible, auditable location — making security review dramatically easier and making it structurally impossible to accidentally skip validation.

What This Means for Linux Users

For end users, the practical implication is significant: many of the CVE security updates pushed to your Linux distribution would simply not exist in the first place if this proposal had been in place from the start. Fewer vulnerabilities at the source means fewer emergency patches, less exposure between disclosure and update, and a meaningfully smaller attack surface.

The proposal is not yet part of the mainline kernel. The Rust compiler still requires some changes to support it, and related development work on domain projection is ongoing. Kroah-Hartman concluded his RustWeek presentation with a call for more Rust kernel developers to join the effort, pointing to the Rust for Linux mailing list as the starting point for newcomers.

Greg Kroah-Hartman’s full presentation is available from RustWeek 2026 (talk begins at 14:27). The Rust for Linux project is hosted on kernel.org and the mailing list is open to new contributors.