Linus Torvalds says AI bug reports have made Linux security list hard to manage

Linus Torvalds says a flood of AI-assisted bug reports has made the Linux kernel security mailing list difficult to manage, mainly because many reports describe the same issues found by different people using similar tools.

The comments came in the Linux 7.1-rc4 release announcement, where Torvalds pointed to new kernel documentation that tightens how AI-found issues should be reported.

The message is not that AI tools have no place in Linux security work. Instead, kernel maintainers want researchers to validate findings, avoid duplicate private reports, and add real value through testing, clear impact analysis, and patches.

What Linus Torvalds said about AI bug reports

Torvalds said the private security list has become overloaded by AI-assisted reports that often identify the same bugs. Maintainers then spend time forwarding reports, redirecting them to the right subsystem, or explaining that an issue was already fixed.

His main argument is that AI-found bugs are often easy for other people to rediscover. Because of that, treating every AI-generated finding as a private security issue can make duplication worse.

The new guidance tells researchers to handle AI-assisted findings differently from urgent, hard-to-discover vulnerabilities that clearly need private coordination.

Issue	Kernel project concern
Duplicate AI reports	Multiple people send the same finding to private lists
Low-quality reports	Maintainers must sort through long or speculative claims
Wrong security classification	Ordinary bugs get treated as private security emergencies
Missing reproducers	Maintainers cannot quickly confirm the issue
No patch included	Reports create triage work without helping fix the bug

AI-found bugs should usually be treated as public

The updated Linux security-bugs documentation says bugs found with AI assistance must be treated as public. The reasoning is practical: the security team has seen these bugs surface across multiple researchers, often on the same day.

That does not mean researchers should publish working exploits. The documentation says reporters should not publicly share a reproducer if it could cause harm. Instead, they should say that a reproducer exists and provide it privately if maintainers ask for it.

The private security list remains available for urgent issues. However, the new rule makes a clearer distinction between bugs that cross a real trust boundary and ordinary bugs flagged by automated or AI-assisted analysis.

What counts as a real Linux security bug?

The Linux documentation says the security list exists for urgent bugs that give attackers a capability they should not have on a correctly configured production system.

The bug should also be easy to exploit and represent an imminent threat to many users. Reports that do not meet this bar should usually go through normal public development channels.

This matters because private handling limits visibility. Public review often leads to better fixes, wider testing, and fewer duplicate reports.

Report type	Recommended path
Urgent, exploitable security flaw	Contact affected maintainers and the kernel security team
AI-assisted bug discovery	Treat as public unless there is a strong reason not to
Ordinary kernel bug	Use normal public reporting and patch channels
Bug with a dangerous reproducer	Mention the reproducer exists, but share it privately on request

Quality rules for AI-assisted reports

The new documentation gives researchers a clearer checklist. AI-assisted reports should be short, plain text, and focused on real impact rather than dramatic theoretical chains.

Maintainers also want reporters to reproduce the issue before sending it. If the reproducer does not work, or the AI tool cannot produce one, the report may not deserve security-list attention.

The strongest reports include a tested fix. Torvalds made the same point in his release note, telling contributors to add value beyond what the AI tool produced.

• Keep the report concise and put the key details first.
• Use plain text instead of heavy Markdown formatting.
• Explain the affected file, function, and kernel version.
• State the verified security impact clearly.
• Test the reproducer before reporting the issue.
• Do not publish exploit details when they could cause harm.
• Propose and test a patch where possible.

Why duplicate reports waste maintainer time

Linux kernel development depends on mailing lists and maintainers who review reports across thousands of files and many subsystems. Even a valid report can create extra work if it goes to the wrong place or lacks basic details.

AI tools can multiply that workload. If many people run similar tools against the same kernel tree, they may all find the same issue and send separate reports to a private list.

Because those private reports are not visible to each other, each sender may believe they found something new. Maintainers then must manually connect the dots.

Torvalds is not rejecting AI tools

Torvalds made it clear that AI tools can help when researchers use them responsibly. The issue is not automated discovery itself, but unfiltered reports with little human review.

Kernel maintainers already use automated tools, fuzzers, static analysis, and AI-assisted workflows to find bugs. Greg Kroah-Hartman has also been publicly associated with AI-assisted bug hunting through his local “Clanker T1000” setup.

The difference is accountability. The Linux process expects a human contributor to understand the issue, test the result, and take responsibility for the patch or report.

Linux also updated its AI contribution rules

The kernel project recently formalized broader rules for AI-assisted contributions. Developers who use advanced coding tools must acknowledge that help with an Assisted-by tag.

The patch submission documentation also reminds contributors that Linux kernel patches must use plain text and follow established mailing-list rules. That helps maintainers quote, review, and merge code properly.

The larger message is consistent: AI can help find or fix bugs, but it does not replace the human contributor’s responsibility.

1. Use AI tools to find possible bugs.
2. Confirm the issue on a real kernel build.
3. Check whether the bug has already been reported or fixed.
4. Write a concise report with verified impact.
5. Send it to the right maintainers.
6. Include a patch when possible.
7. Disclose AI assistance when it contributed to the patch.

Why this matters for open-source security

The Linux kernel is one of the most important open-source projects in the world. It powers servers, phones, embedded devices, routers, cloud infrastructure, and developer systems.

That makes kernel security work highly sensitive. A flood of poorly triaged reports can delay attention for real vulnerabilities and frustrate the maintainers who need to fix them.

The new rules try to keep the useful part of AI-assisted bug discovery while reducing noise. Researchers can still use AI tools, but the Linux project now expects better filtering before reports reach maintainers.

What researchers should do next

Researchers who use AI tools against the Linux kernel should read the updated security-bugs documentation before sending reports. The documentation explains when to use the private security process and when to report publicly.

They should also avoid sending raw AI output. A useful report should look like normal kernel engineering work, not a tool transcript.

For maintainers, the change may reduce duplicate private reports over time. For researchers, it raises the bar: finding a possible bug is only the start of the work.

FAQ