Artificial intelligence promised to save developers time, but in some free software projects it is beginning to do the opposite. The Linux kernel community is facing a flood of bug reports and alleged vulnerabilities generated with AI tools, many of them duplicated, poorly reviewed or submitted without enough human validation.
The problem is not that AI cannot find real bugs. In fact, it already can. The problem is that more and more people are using similar tools to analyse the same code, finding the same possible issues and submitting almost identical reports to maintainers. The result is a longer review queue, more noise and less time to fix important problems.
Linus Torvalds points to the problem: too many reports, too little value
Linus Torvalds, creator of Linux and the main maintainer of the kernel, has been particularly clear in describing the situation. In a message related to Linux 7.1-rc4, he warned that the continuous flow of AI-generated reports had made the private kernel security list “almost entirely unmanageable”. The main reason is duplication: different people find the same alleged bugs using the same tools and submit them as if they were unique findings.
Torvalds does not reject the use of AI in development or security research. His criticism is aimed at automatic or poorly understood submissions. A report that simply pastes the output of a tool, without proving impact, reproducing the bug or providing a fix, is not very helpful. In many cases, it forces a maintainer to check whether the problem exists, whether it has already been fixed, whether it actually affects the kernel or whether it is simply a mistaken interpretation by the model.
The situation is especially delicate in security. Private lists exist to deal with sensitive vulnerabilities before they become public, but Torvalds argues that a bug detected by widely used AI tools should not be treated as secret by default. If several people can reach the same result with the same type of analysis, sending it to a closed list can make the problem worse: reporters do not see that others have already submitted it, and maintainers end up reviewing the same thing again and again.
AI is finding real bugs, but it is also multiplying the noise
The open source community is going through an uncomfortable transition. A few months ago, many AI-generated reports were easy to dismiss: confused reasoning, non-existent vulnerabilities, misunderstood code paths or explanations that did not match how the project actually worked. That kind of “AI slop” still exists, but some tools have improved and valid reports are now appearing too.
Greg Kroah-Hartman, one of the long-standing maintainers of the Linux kernel, recently acknowledged that there has been a shift: AI-generated reports are no longer just rubbish; they can also point to real bugs. The nuance matters. The fact that a finding is real does not mean it is ready to be submitted as-is. A maintainer needs a clear explanation, reproduction steps, context, impact and, if possible, a patch.
The “Copy Fail” case shows the other side of the phenomenon. This vulnerability, identified as CVE-2026-31431, affected the Linux kernel and allowed local privilege escalation through a weakness in the cryptographic subsystem. According to Xint, the finding was AI-assisted, but it started from a human technical intuition and a targeted investigation into a specific kernel surface. It was not simply a matter of asking a model to “find bugs” and forwarding its answer.
That is the point that separates useful use from irresponsible use. AI can expand a researcher’s analytical capacity, speed up code review and help explore complex paths. But without human judgement, it can turn every repository into a factory of speculative reports.
The problem affects all free software
Linux is not the only affected project. Other open source projects have been warning about the same trend for some time. The curl team, for example, decided to end its security bounty programme after receiving a growing volume of low-quality reports, many of them generated with AI or automated tools. For projects maintained by small teams, every false positive can mean hours of analysis taken away from real development.
The Open Source Security Foundation (OpenSSF) is already discussing how to respond to the phenomenon. Ideas include creating guidelines to identify AI-generated reports, preparing policy templates for AI-assisted contributions, requiring human validation and making clear that the goal should not be to ban AI, but to reduce noise.
GitHub has also raised the bar in its bug bounty programmes. Its position is reasonable: it does not matter which tool was used; what matters is the quality of the report. An AI-assisted finding that is verified, reproducible and accompanied by a functional proof of concept can be a valuable contribution. A text with no validation, no demonstrated impact and sent in bulk is just noise.
What a good AI-assisted vulnerability report should include
The debate should not end with “AI yes” or “AI no”. The useful question is how AI can be used without shifting the validation cost onto maintainers.
A responsible report should include a brief description of the issue, exact steps to reproduce it, the environment in which it was tested, the real impact, a proof of concept and references to the affected code. If the user has used AI, they should say so transparently, but that does not exempt them from understanding what they are submitting. Responsibility still lies with the person signing the report.
Providing a patch also helps. Torvalds was clear on that point: if someone wants to add value, they should read the documentation, understand the bug and, where possible, propose a fix. The maintainer does not need more administrative work; they need contributions that reduce the workload, not increase it.
Security reporting platforms will have to adapt. More filters, submission limits, proof-of-concept requirements, researcher reputation systems and tools to group duplicates are likely to appear. AI itself may even be used to classify AI-generated reports, although that does not remove the need for human review.
A new stage for open development
The pressure on maintainers reveals something deeper: the economics of bug detection have changed. Finding a vulnerability used to require a lot of time, experience and manual code reading. Now, increasingly accessible tools can analyse large codebases and produce suspicions at high speed. That democratises part of security research, but it also lowers the cost of generating noise.
For huge projects such as Linux, the impact is annoying but manageable with process changes. For smaller projects, it can be much more serious. A maintainer working in their spare time cannot spend entire afternoons verifying reports produced by a model that the submitter has not even understood.
The solution will not be to close the door to artificial intelligence. That would be unrealistic and would also mean losing valuable findings. The solution is to demand the same standard as always: reproducibility, clarity, impact and responsibility. AI can be a magnifying glass; it should not become an excuse to submit work without reviewing it.
Linux is showing earlier than other projects a tension that will soon become common across software. AI can help find more bugs, but if it is not used carefully, it can saturate the very channels that are supposed to help fix them. In security, finding a bug is only the beginning. What really matters is proving it, explaining it clearly and helping to fix it.
Frequently asked questions
What is happening with Linux and AI-generated reports?
Linux kernel maintainers are receiving many bug and vulnerability reports generated with AI tools, often duplicated or lacking enough human validation.
Is Linus Torvalds against using AI to find bugs?
No. His criticism is aimed at reports submitted without understanding the issue, without reproducing it and without adding value, such as a patch or a solid technical explanation.
Can AI find real vulnerabilities?
Yes. Cases such as Copy Fail show that AI can help discover important flaws, as long as it is part of a targeted investigation validated by people with technical judgement.
What should a good AI-assisted security report include?
It should include reproduction steps, a working proof of concept, demonstrated impact, test environment, clear explanation and, if possible, a proposed patch.