AI Is Finding Linux Bugs Faster Than Anyone Can Fix Them. That's Not Going Away.
Three Linux vulnerabilities in quick succession — Dirty Frag, Copy Fail, and Fragnesia — share more than a catchy naming convention. All three exploit the same kernel abstraction: the page cache. More importantly, all three are early evidence of what happens when AI tools start systematically crawling through kernel code looking for weaknesses.
CloudLinux CEO Igor Seletskiy put it plainly: normally you might see one or two kernel-level privilege escalation vulnerabilities affecting multiple distros in an entire year. We just saw two in the same week. His prediction — that server admins could end up rebooting weekly to stay patched — isn't hyperbole. It's an extrapolation of a trajectory that's already in motion.
Linus Torvalds addressed this head-on at Open Source Summit North America in Minneapolis. He noted that the old approach — quietly tipping off distro maintainers and hoping nobody noticed what changed — is finished. AI tools can analyse a patch and reconstruct the underlying vulnerability in hours. According to Torvalds, after one recent fix landed, a detailed blog post about its security implications appeared within three hours. The cat is basically always out of the bag now.
This forced a rethink. Torvalds' conclusion is that AI-discovered bugs simply cannot be kept confidential. Treating them as private disclosures wastes everyone's time, especially since the person who found a bug with an AI tool should assume a hundred other people found the same bug the same way. Duplicates are already a serious problem. OpenSSF's chief security architect Christopher Robinson told The Register that around 30 percent of reported Linux security bugs are now duplicates, largely because anyone with a cloud coding subscription can play security researcher. The result is a growing pile of redundant reports for already-stretched maintainers to sort through.
Greg Kroah-Hartman, who maintains the Linux stable kernel, is cautious about declaring a crisis. His take: the recent vulnerabilities are fairly minor in practice, because systems with genuinely untrusted local users aren't that common. He doesn't see an unusual spike in actual bug fixes. What he does see is an appetite for bug-naming and public exploit releases — which is a different kind of problem, more reputational and operational than purely technical.
Red Hat CTO Chris Wright made a useful point at Red Hat Summit: not all vulnerabilities are equal. Some need immediate, high-priority responses. Others sit at the lower end of the severity spectrum and can be dealt with more methodically. The risk is that AI-accelerated discovery floods the pipeline with everything at once, making triage harder rather than easier.
Torvalds also pushed back on the idea that this is a Linux-specific problem. Closed-source software like Windows is in a worse position, not a better one. AI can reverse-engineer proprietary binaries just as readily — but with closed source, the AI can help attackers find vulnerabilities without being able to help defenders fix them. Open source at least has the advantage of transparency on both sides.
He also had a quiet word for researchers tempted to publish working exploits: don't. Finding a serious vulnerability is one thing. Publishing a functional exploit that can be used to compromise real systems just for the attention is another.
The most sobering datapoint in all of this comes from Google's Threat Intelligence Group. Mean time to exploit has collapsed — from 63 days in 2018 to negative figures in recent years. By 2025 estimates, exploitation is occurring, on average, seven days before a patch exists. That's not a gap that better disclosure practices will close on their own.
None of this means Linux has become less secure in any fundamental sense. What's changed is the detection capability, and that cuts both ways. AI is surfacing bugs that would have remained hidden for years. Some of those bugs are serious. Patches will sometimes arrive after exploits are already in the wild.
For system administrators, the practical response is less exciting than the headlines. Wright's suggestion to move SELinux from permissive to enforcing mode is unglamorous but sensible. Strict security controls are annoying until the moment they're the only thing standing between you and a full rebuild.