Rust Could Eliminate 80% of Linux Kernel CVEs!
Rust Could Eliminate 80% of Linux Kernel CVEs!
https://itsfoss.com/news/linux-kernel-rust-cve-reduction/
Publish Date: 2026-05-21 09:23:00
Source Domain: itsfoss.com
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 spot
Greg’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 fixes
Before 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” type
Greg’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…