Linus Torvalds has had enough. In his latest release post for Linux 7.1-rc4, published on Sunday, May 17, the Linux creator made a blunt admission: the kernel’s private security mailing list has become almost entirely unmanageable. The culprit? A relentless flood of AI-generated bug reports, many of which are duplicates or irrelevant. Torvalds described the situation as entirely pointless churn, signaling a critical inflection point for open-source security workflows. The private list, originally designed for urgent, exploitable vulnerabilities with real-world impact on production systems, is now drowning in reports better suited for public development channels.

Multiple researchers are independently using the same AI scanning tools, discovering the same issues simultaneously. They bombard the private security list with duplicate reports, often for bugs that were already fixed weeks or months earlier. Kernel maintainers, already stretched thin across hundreds of subsystems, are now functioning as de facto triage bots for AI-generated noise. They spend all their time forwarding messages to the right people or replying with variations of that was already fixed a week or a month ago. This is not how security is supposed to work.

The Scale of the AI Bug Spam Problem

Willy Tarreau, a kernel veteran, authored new Linux 7.1 security documentation that was merged ahead of the rc4 release. It confirms the scale of the problem. Bugs discovered with AI assistance systematically surface simultaneously across multiple researchers, often on the same day. The updated documentation makes a clear policy distinction: AI-detected bugs are pretty much by definition not secret. Routing them through the private security list wastes time for everyone involved and worsens the duplication problem, since reporters cannot see each other’s submissions.

Most security-adjacent bugs sent to the private list turn out to be regular bugs that have been improperly qualified as security bugs. This happens because many developers lack awareness of the Linux kernel’s threat model. They see a crash or a potential buffer overflow and assume it’s a security issue, when in reality, it might be a harmless corner case on a correctly configured production system.

Policy Shift for AI-Assisted Findings

Going forward, AI-assisted findings should default to public reporting unless the vulnerability meets strict criteria. It must offer an attacker an unexpected capability on a correctly configured production system. It must also be both urgent and easily exploitable. Exploit code remains an exception: reporters may confirm a working exploit privately upon a maintainer’s request, but they should not distribute it publicly. Torvalds was characteristically blunt in his RC4 post. If you found a bug using AI tools, the chances are somebody else found it too. He added that if you actually want to add value, you should read the documentation, create a patch, and add some real value on top of what the AI did.

The kernel project isn’t banning AI-assisted security research. That would be impractical and counterproductive. But it is demanding that contributors graduate beyond drive-by reporting. Contributors must bring patches, context, and genuine understanding to the table. A report without a fix is just noise. A report without understanding is spam.

Systemic Tension Across Open Source

This incident underscores a systemic tension emerging across open-source ecosystems. Automated vulnerability scanning scales exponentially faster than human review capacity. Without discipline, the tools meant to harden security can paralyze the very teams responsible for it. Imagine a fire department inundated with false alarms every single day, from every corner of the city. Eventually, the firefighters stop trusting the alarms, and real emergencies get missed. That is precisely the risk the Linux kernel faces now.

There is also a human cost. Kernel maintainers are volunteers or underpaid specialists who pour countless hours into reviewing code, fixing bugs, and managing community relations. When they spend most of their day triaging AI-generated duplicates, they have less time for genuine security patches, performance improvements, and architectural decisions. The irony is palpable: tools designed to improve security are degrading the security team’s effectiveness.

For developers who want to contribute meaningfully, the message is clear. Run your AI scanners, but do not just dump the output onto a mailing list. Verify the findings. Check if the bug has already been reported. Write a patch. Provide context about why this matters in a real-world deployment. The kernel community has always valued patches over complaints, and that principle now extends to AI-generated bug reports.

The broader implications are still unfolding. Other open-source projects will likely face similar challenges as AI tooling becomes more accessible and more powerful. The Linux kernel’s response may serve as a template for the industry. By establishing clear boundaries between public and private reporting, and by demanding more from reporters, the kernel project is trying to restore sanity to its security workflow. Whether other communities follow suit remains to be seen, but one thing is certain: the age of drive-by AI bug reporting is over.