For years, the Linux kernel security mailing list served as a controlled channel where serious vulnerabilities could be discussed privately before public disclosure. That workflow has changed dramatically. Linus Torvalds, the creator of Linux, recently announced that the list has become “almost entirely unmanageable” due to a surge in automated submissions. The root cause? Multiple security researchers now rely on identical AI tools to scan the kernel code, and those tools keep flagging the same bugs. This creates a flood of duplicate reports that buries meaningful communication.
The situation has frustrated Torvalds enough that he used his weekly kernel status update to call out the trend directly. In his blunt style, he described the resulting work as “unnecessary pain and pointless make-believe work.” His remarks offer a rare window into how AI-generated content can overwhelm even the most organized open-source communities.
The Scale of the AI Bug Flood on the Linux List
Torvalds did not share exact numbers, but his language made the severity clear. He said people on the list now spend all their time forwarding reports to the correct teams or responding with variants of “that was already fixed a week or a month ago.” That time adds up fast. When dozens of researchers run the same large language model or static analysis tool against the same kernel tree, the overlap is enormous.
The core problem is not that AI tools find bugs. It is that they find the same bugs repeatedly. Each researcher who runs the tool believes they have discovered something new. In reality, the tool has simply reproduced a finding that someone else already submitted a week earlier. This dynamic creates a negative feedback loop. The more people use a given AI tool for kernel scanning, the more duplicate reports arrive. The more duplication there is, the less time maintainers have to review genuinely novel vulnerabilities.
How the Mailing List Became a Duplicate Repository
The Linux kernel security list was designed for privacy. Researchers send a report, and maintainers discuss it away from public view until a fix is ready. But when AI tools generate the reports, the assumption of privacy breaks down. As Torvalds pointed out, AI-detected bugs are “pretty much by definition not secret.” The tools are public. The code is public. Anyone can run the same scan. Treating such reports on a private list wastes everyone’s time and, ironically, makes the duplication worse because submitters cannot see each other’s work.
Another layer of frustration is that many of these reports arrive without context. A typical AI-generated submission might flag a potential buffer overflow or an out-of-bounds access but offer no proof of exploitability. The reporter often has no deep understanding of the code path involved. That forces a senior maintainer to investigate whether the finding is real, whether it has already been fixed in a newer tree, and whether it warrants a CVE. Multiply that effort by hundreds of reports, and the list becomes unmanageable.
Why AI Tools Create So Many Overlapping Results
The duplication is not a coincidence. It is a structural outcome of how most AI-powered vulnerability scanners work. These tools often train on the same datasets, use similar heuristics, and target the same types of weaknesses. When multiple researchers point the same model at the same codebase, the output sets look nearly identical.
Consider a concrete scenario. Two researchers, Alice and Bob, each download the latest kernel source tree. Alice runs a popular LLM-based scanner that flags a certain memory allocation pattern. Bob runs a different tool that also uses a transformer model trained on similar CVE examples. Both tools highlight the same three lines of code. Alice submits a report on Monday. Bob submits his on Wednesday, unaware that the issue is already being discussed. The maintainer now has two threads to merge, two conversations to manage, and two submitters to update.
This is not a hypothetical edge case. Torvalds confirmed that the pattern repeats daily. The result is a list that serves more as a notification system for known issues than a discovery pipeline for fresh vulnerabilities.
Readability Is Lost in the Noise
Maintainers rely on the signal in each report to decide priority. When the report is a raw AI dump with no human reasoning, the signal is weak. The maintainer cannot tell whether the finding is a true vulnerability, a false positive, or a corner case that the kernel already handles safely. In many cases, the report does not include a patch or even a suggested fix. It simply says, “This code might be unsafe.” That level of detail is not actionable without hours of additional investigation.
Linus Torvalds’ Blunt Solution for AI Bug Reports Linux
Torvalds did not mince words. In his weekly update, he directed kernel contributors to the project’s documentation on handling AI-generated bugs. He then offered his own summary: “AI tools are great, but only if they actually help, rather than cause unnecessary pain and pointless make-believe work.” His advice breaks down into three clear rules.
Rule One: Assume Someone Else Found It First
Torvalds stated directly that if you found a bug using an AI tool, the chances are high that someone else found it too. Before submitting, researchers should check the existing threads on the public mailing lists. They should also search the kernel’s bug tracking system and recent patches. A few minutes of searching can prevent hours of wasted maintainer time.
Rule Two: Add Real Value on Top of the AI Output
The most productive way to use an AI tool is not to copy its output into an email. It is to read the documentation for the affected subsystem, understand the root cause, and create a patch. If the AI tool flags a potential issue, the researcher’s job is to confirm whether the issue is real and, if so, to propose a concrete fix. A patch is infinitely more valuable than a report. It moves the project toward a solution rather than adding to the backlog.
Rule Three: Do Not Be a Drive-By Reporter
Torvalds used the phrase “drive-by ‘send a random report with no real understanding’ kind of person” to describe the least helpful type of contributor. A drive-by reporter runs a tool, gets an output, and forwards it without context. They have no stake in the fix. They do not engage with the maintainers’ questions. They simply generate noise. Torvalds urged researchers to avoid that behavior entirely.
How the Linux Community Normally Handles Bug Submissions
Before the AI flood, the kernel project had a well-established workflow for security bugs. Researchers would send a detailed report to the security list. That report would include a description of the vulnerability, a proof of concept if possible, and sometimes a suggested patch. Maintainers would then discuss the issue privately, develop a fix, and coordinate a release date. After the fix shipped, the discussion would become public.
That workflow assumed that each report was unique and came from someone who understood the code. The AI flood broke both assumptions. Now, many reports are duplicates, and many come from people who cannot explain the vulnerability in their own words. The old process cannot handle the volume.
Greg Kroah-Hartman’s Counterpoint on AI Utility
Fellow kernel maintainer Greg Kroah-Hartman recently offered a more measured perspective. He told The Register that AI has become an increasingly useful tool for the FOSS community. While he acknowledged the duplication problem, he also noted that AI tools help find bugs that human reviewers might miss. The challenge is not the tool itself. It is how the tool is used.
Kroah-Hartman’s view aligns with Torvalds’ core message. The tool can be productive, but only when the user brings understanding and a willingness to contribute meaningfully. A report without context is noise. A report with a patch is a contribution.
Practical Lessons for Open-Source Maintainers Facing AI Floods
The Linux kernel is not the only project dealing with this problem. Any open-source project with a public bug tracker will eventually face similar challenges. Maintainers can learn from Torvalds’ response and apply preventive measures early.
Set Clear Expectations in Your Contributor Documentation
The Linux kernel project now has explicit documentation about AI-generated submissions. Other projects should do the same. Spell out what a good report looks like. State clearly that AI output alone is insufficient. Require that researchers confirm each finding manually before submitting. The documentation acts as a first filter.
You may also enjoy reading: 74% of Firms Roll Back Customer Service Bots: 5 Key Reasons.
Consider Pre-Submission Validation Steps
Projects can add automated checks on the submission side. For example, before a bug report is accepted, the system could search for existing reports with similar code locations or error descriptions. While this duplicates some maintainer work, it catches duplicates early. It also teaches submitters to check for existing reports before hitting send.
Encourage Patch-Submission Culture
If a project rewards reports and patches equally, it will get more reports. If it explicitly prioritizes patches, contributors will invest time in understanding the code and writing fixes. Torvalds’ advice to “create a patch too” is a cultural lever. It shifts the incentive from volume to quality.
What Security Researchers Should Do Differently
If you are a security researcher using AI tools to scan Linux or any other open-source project, the message is clear. Your goal should not be to generate the highest number of reports. It should be to produce the highest quality findings. Here is a practical checklist that aligns with Torvalds’ expectations.
Step One: Run Your Scan Against the Latest Tree
Always pull the most recent kernel source before scanning. Many bugs that AI tools flag have already been fixed in a commit from last week. Checking the latest tree eliminates a large fraction of false positives and duplicates.
Step Two: Search Existing Reports and Patches
Before you write a report, search the kernel mailing list archives, the bug tracker, and recent patch submissions. If you find a thread about the same issue, add your analysis there. Do not open a new thread. This reduces noise and helps maintainers see all relevant information in one place.
Step Three: Investigate Until You Can Explain the Bug Without the Tool
The AI tool is a starting point, not an authority. Read the affected code. Understand the data flow. Determine whether the issue is exploitable. If you cannot explain the vulnerability in your own words, you are not ready to submit a report. Keep investigating until you can.
Step Four: Write a Patch or at Least a Concrete Fix Suggestion
A patch is the most valuable output you can produce. If you cannot write a full patch, write a detailed description of the fix. Identify the function that needs to change and describe the correct logic. This shows that you have done the work and that your report is serious.
Step Five: Be Prepared to Engage in the Discussion
Do not drop a report and walk away. Maintainers may ask clarifying questions. They may need you to test a proposed fix. They may discover that the issue is more complex than it first appeared. If you are not willing to engage, you are part of the noise. If you are willing to engage, you are part of the solution.
The Irony of AI Tools Intended to Improve Security
There is a bitter irony in the current situation. AI tools were supposed to make software more secure by finding bugs faster. Instead, in the Linux kernel project, they have created a bottleneck that slows down the entire vulnerability management pipeline. The tools are not the problem. The culture of how they are used is the problem.
When a tool produces output that no human validates, the output is not knowledge. It is data. The difference between data and knowledge is understanding. The kernel project needs knowledge, not data. The challenge for the community is to build norms that transform raw AI output into understanding and, from that understanding, into patches.
A Path Forward for AI-Assisted Vulnerability Research
The path forward requires maturity from both tool developers and tool users. Developers should design tools that highlight uncertainty, suggest verification steps, and link to existing reports. Users should treat the tool as a collaborator, not a replacement for their own judgment.
Kroah-Hartman’s optimism suggests that the community can adapt. The kernel project has weathered many changes over three decades. This one is about managing volume, not about a fundamental flaw in the approach. With clearer documentation, better cultural norms, and a commitment to quality over quantity, the Linux security list can become manageable again.
Torvalds’ message, as blunt as it was, is a call for contributors to level up. If you use an AI tool, use it as a starting point for deeper work. Do not be the person who sends a random report with no understanding. Be the person who reads the documentation, creates a patch, and adds real value. That is the difference between noise and contribution. That is the difference between a flooded inbox and a productive security process.
