Linux's Rust shift: 80% of kernel CVEs could vanish

Key Takeaways

• Greg Kroah-Hartman estimates 80% of Linux kernel CVEs would be prevented by Rust's memory safety
• Some Linux subsystems will only accept Rust code going forward
• The kernel sees about 13 CVEs daily, most from simple C memory mistakes

Greg Kroah-Hartman, the Linux stable kernel maintainer, declared at Open Source Summit India 2026 that "the Rust experiment is over. It's real." Speaking in Mumbai, he made a claim that should get the attention of anyone running Linux infrastructure: 80% of kernel security vulnerabilities would simply not exist if the code had been written in Rust instead of C.

That's not a throwaway number. Kroah-Hartman oversees the kernel CVE process and has reviewed every vulnerability filed against Linux for 25 years. The kernel currently logs about 13 CVEs per day, and he argues most stem from "small, trivial, little bugs" that Rust's compiler catches automatically.

Why a C veteran became a Rust convert

Kroah-Hartman didn't start as a Rust enthusiast. When a friend first pitched him on the language, his response was blunt: "What? No, C is great." The friend persisted, telling him Rust makes programming fun again. Kroah-Hartman dismissed the idea.

He now admits he was wrong. "I should have done it then," he said. "Rust is actually fun. It takes a lot of stuff away from having to worry about the compiler, which can fix a lot of your problems for you, and it makes code a little bit better."

The technical case centers on Rust's ownership and type system. These features eliminate entire categories of bugs that plague C code: unchecked pointers, forgotten unlocks, sloppy cleanup paths. These aren't exotic attack vectors. They're the mundane mistakes that consume maintainer time and create security holes.

The reviewer bottleneck drives the decision

Linux has over 5,000 developers submitting code. Only about 150 core maintainers review the majority of it. This ratio shapes everything.

"We optimize for reviewers. We don't optimize for developers because we have a lot of developers," Kroah-Hartman explained. Rust shifts the burden. When the compiler enforces locking and lifetime rules at build time, reviewers can focus on logic instead of hunting for memory bugs. "If it builds as a reviewer, I know it's OK. I can look at the logic."

Rust already improved the C code

An unexpected benefit: making Rust bindings safe forced maintainers to revisit C APIs that had been unchanged for years. They added guard and scoped-allocation mechanisms that mirror Rust's automatic cleanup patterns.

"We have the guards, the scoped reference counting, to C because Rust showed us we could," Kroah-Hartman said. "We added a lot more memory safety stuff to the kernel and other APIs because we realized Rust showed us we could do that, and we made the C code more reliable and better."

His conclusion was pointed: "If Rust were to disappear tomorrow, the kernel's better off for it."

What this means for new kernel development

Kroah-Hartman confirmed that some Linux subsystems will only accept Rust code going forward. This is a significant policy shift. C won't vanish from the kernel anytime soon. The existing codebase is massive, battle-tested, and rewriting it would be impractical. But the direction is clear: new work in key subsystems will default to Rust.

He's careful not to oversell. Rust won't fix logic bugs. "Rust will still crash just fine. You can do really foolish things in Rust," he acknowledged. The remaining 20% of vulnerabilities that Rust can't prevent are the ones he actually wants maintainers spending time on.

The broader industry shift

Linux isn't alone. Git is moving toward Rust. The pattern appears across infrastructure software where reliability and security justify the investment in a new language. Major technology companies report that 70% of their security vulnerabilities in large codebases stem from memory safety issues, exactly the class of bugs Rust prevents at compile time.

For CTOs and engineering leads running Linux-based infrastructure, this shift matters beyond kernel internals. It signals where the talent pool is heading, which skills will be in demand, and how foundational software will evolve over the next decade.

Frequently Asked Questions

Will the Linux kernel be completely rewritten in Rust?

No. Kroah-Hartman made clear that the existing C codebase won't be rewritten. The shift applies to new development in certain subsystems, not wholesale replacement.

What percentage of kernel CVEs could Rust prevent?

Kroah-Hartman estimates 80%, based on his review of kernel vulnerabilities over 25 years. These are primarily memory safety bugs that Rust's compiler catches automatically.

When did Rust first enter the Linux kernel?

Rust infrastructure support was first merged in Linux 6.1, released in December 2022. Kroah-Hartman now considers it a permanent part of the kernel.

Does Rust eliminate all security bugs?

No. Rust prevents memory safety bugs but not logic errors. Kroah-Hartman noted that "Rust will still crash just fine" if the underlying logic is flawed.

Why does the kernel optimize for reviewers over developers?

Linux has over 5,000 developers but only about 150 core maintainers who review most code. Rust's compile-time safety checks reduce reviewer workload on routine memory bugs.

Source: Latest news