Linux Kernel Maintainer Greg Kroah-Hartman Says Rust Would Have Prevented 80% of Kernel Security Bugs

The pitch: less busywork for the people who catch bugs

Greg Kroah-Hartman, the Linux stable-kernel maintainer, told an audience at Open Source Summit India 2026 in Mumbai that "the kernel is moving toward Rust," pointing to Git and other major projects making the same shift, according to ZDNET.

His number: the kernel racks up about 13 CVEs a day, and the project has averaged nearly nine code changes an hour for over a decade. Kroah-Hartman said most of those vulnerabilities aren't sophisticated attacks. They're plain C mistakes: unchecked pointers, forgotten unlocks, sloppy cleanup code.

His estimate, which he explicitly labeled unscientific, is that Rust's compiler-enforced ownership and type system would have caught about 80% of every kernel CVE he's reviewed over 25 years. He didn't pretend Rust is a cure-all. "Rust will still crash just fine," he said, according to ZDNET. "You can do really foolish things in Rust, but all the tiny, stupid, trivial things Rust will handle for us."

Why a C loyalist changed his mind

Kroah-Hartman wasn't always on board. He recounted a friend pushing him toward Rust years ago and him brushing it off, insisting C was fine and programming was already fun. He now says the friend was right. "Rust is actually fun," he said. "It takes a lot of stuff away from having to worry about the compiler, which can fix a lot of your problems for you."

Kroah-Hartman has run the kernel's CVE process and has as much visibility into where things actually break as anyone alive. His argument isn't really about language aesthetics. It's about maintainer bandwidth. Linux has more than 5,000 developers contributing code, but only about 150 core maintainers doing the bulk of the reviewing, according to ZDNET. Kroah-Hartman said explicitly that the project "optimizes for reviewers," not for the convenience of whoever's submitting a patch.

A compiler that automatically rejects a whole category of bugs before a human reviewer ever has to spot them is a real workload reduction for 150 people trying to review code from 5,000. It doesn't require anyone to love Rust as a language. It just requires trusting the arithmetic.

The C camp's actual argument, and it's not nothing

The pushback against Kroah-Hartman's framing isn't "C is perfect." Longtime C and C++ developers, including contributors discussing the issue on LWN, have pointed out that a lot of what gets labeled undefined behavior in C is code written deliberately, with architecture-specific guarantees in mind, by engineers who know exactly what their target CPU does.

In one exchange documented on LWN, a HAProxy developer defended an unaligned-memory-access shortcut as intentional and safe on the specific architectures the project supports, not a "cheat," arguing it's gated behind conditional compilation checks and has run reliably across sparc, mips, riscv64, arm, and x86 for years. Other commenters countered that this is precisely the trap: the code works today because of what a given compiler and CPU currently tolerate, not because the C standard guarantees it will keep working.

Experienced C developers aren't wrong that raw hardware-level control has real value for performance-critical code, and that the language's flexibility is a feature when you know what you're doing. The problem Kroah-Hartman is describing isn't that expert C programmers can't write safe code. It's that a kernel with 5,000 contributors and 150 reviewers can't guarantee every one of those contributors is an expert, or that every reviewer catches every mistake, 13 times a day, forever.

Where this actually stands

Rust support in the Linux kernel isn't hypothetical at this point. It has been merged incrementally over several kernel releases, primarily for drivers and specific subsystems, rather than as a wholesale rewrite of the core kernel. Kroah-Hartman's comments in Mumbai reflect an acceleration of that trend, not the start of it.

What's unresolved is scope and timeline. Nobody on record, including Kroah-Hartman, is proposing to rewrite the existing multi-million-line C codebase in Rust. The near-term fight inside the kernel community has been over how much new code gets written in Rust going forward, how quickly older maintainers who don't know Rust are expected to review Rust patches, and whether the "80%" figure holds up if independently audited against the kernel's actual CVE database rather than one maintainer's recollection. An actual data-backed audit of kernel CVEs by root cause doesn't appear to have been published, and it's the study that would settle the argument either way.