Linus Torvalds vs. the AI Slop Flood Drowning Linux Security

Linus Torvalds is exasperated again. This time it isn’t broken code — it’s his inbox. AI-generated vulnerability reports are flooding the Linux kernel security mailing list, and the maintainers who should be hunting real bugs are spending their days shoveling slop.

When Linus says “unmanageable,” pay attention

Torvalds throws elbows on the mailing lists routinely, but he usually targets specific code or specific decisions. Hearing him publicly call an entire process unmanageable is different. That’s not a flame — that’s a flag that the operational model has broken.

What’s clogging the pipes: LLM-generated reports with convincing CVE numbering, plausible-looking snippets, and confident impact analysis. Dig in and they fall apart. They cite functions that don’t exist. They flag already-patched code as new bugs. They describe “critical vulnerabilities” in code that doesn’t even compile.

Why security reports became slop magnet number one

The incentives explain everything. Bug bounty programs pay real money, and platforms like HackerOne tie reporter reputation directly to submission volume. Add an LLM and you don’t need to read code or understand memory safety. “Write me a use-after-free CVE report for the Linux kernel” yields a credible-looking document in 30 seconds. Paste, send, repeat.

Maintainers can’t just trash it. If there’s even a 1% chance a real bug is buried in the noise, somebody has to verify. Thirty minutes per report, dozens per day — and the day is gone before any actual kernel work happens.

Daniel Stenberg saw this coming

This isn’t new. Daniel Stenberg of curl has been shouting about it for years, with the now-famous line that AI slop is killing us. He’s documented the time and mental cost of triaging fake reports in painful detail, and eventually pushed HackerOne to change its policies.

The fact that the Linux kernel security team is now in the same trench tells you this isn’t a project-specific issue. It’s a structural problem in open source. Maintainers are mostly unpaid volunteers or a thin layer of funded engineers. LLMs can generate reports infinitely, around the clock, for pennies. The asymmetry isn’t sustainable.

The fixes on the table — and why none of them are clean

Three proposals keep circulating. First, stricter submitter identity — auto-deprioritizing reports from throwaway accounts. Second, mandatory working PoCs — no proof-of-concept, no review. Third, reject on suspected AI generation.

Each has a real downside. Tightening identity pushes away legitimate security researchers who depend on pseudonymity, and that’s a non-trivial slice of the community. Requiring PoCs filters out entire bug classes that can’t be demonstrated without privileged access. And detecting AI-generated text is already a losing arms race — the models keep getting better at sounding human.

The real risk isn’t tired maintainers

The scary part isn’t burnout, though that’s bad enough. It’s alert fatigue at scale. When a maintainer has triaged 100 garbage reports, the 101st — a genuine zero-day — gets the same reflexive shrug. “Probably more AI slop.” That’s not hypothetical. That’s how compromises happen.

Some researchers are already warning about the next move: attackers deliberately seeding slop into security channels to camouflage a real exploit submission. Use the noise as cover. It’s a clean playbook, and it’s enabled by exactly the dynamic Torvalds is describing.

That’s why this isn’t just Linus being Linus. The trust infrastructure underneath open source security is being stress-tested by a tool that costs nothing to weaponize. Before we celebrate AI writing code, we should figure out who cleans up after the AI writing reports about that code. The maintainer of the library your stack depends on is, right now, probably reading a fake CVE.