Greg Kroah-Hartman was at RustWeek 2026 in Utrecht this week, and he talked about a Rust-based proposal still in development that could wipe out around 80% of the CVEs the Linux kernel generates.That is not a small claim. This is coming from someone who has personally reviewed every kernel security bug since the Linux kernel security team was formed in 2005.C's blind spotGreg's presentation starts at 14:27.The core problem, as Greg sees it, is untrusted data. Every time data arrives from user space or from hardware, the kernel should treat it with suspicion. C has never had a reliable way to enforce that.Once data gets copied from user space into the kernel, it becomes a regular pointer and loses all context about where it came from. It gets passed around freely, and the external checkers that should catch issues do not always get run.Hardware adds another layer of the same problem. The kernel was designed assuming hardware is trustworthy, and that assumption is getting harder to hold as malicious hardware becomes a real and growing threat.What Rust already fixesBefore the new proposal even ships, Rust is already making a difference. Failing to check error return values and forgetting to release locks are two notable contributors to kernel CVEs, and Rust handles both at compile time. Greg estimates those two fixes alone cover around 60% of kernel bugs.And it doesn't stop there. Writing Rust bindings for existing C code has quietly pushed kernel maintainers to actually document and think through their APIs, working out ownership semantics, lock rules, and const-correctness.Enter, the "untrusted" typeGreg's proposed solution is a Rust type called Untrusted, developed with kernel contributor Benno Lossin. It attaches to data coming in from user space or hardware as a compile-time marker, with no runtime cost. And you cannot access the underlying data without going through a validation step that explicitly converts it to trusted. That pushes all validation code into one visible, reviewable spot.What this means for you as a Linux user? A significant number of the CVEs that currently trickle down to your distro as security updates simply would not exist in the first place.But, it is not merged yet. Changes are still needed in the Rust compiler, and related work on field projections is running alongside it. Greg concluded his presentation by asking for more Rust kernel developers, and pointed towards the Rust for Linux mailing list as the starting point.Suggested Read 📖: Fedora Pulls the Plug on Deepin