The Kernel's New Rules for AI Bug Reports

Introduction

#

When Linus Torvalds released Linux 7.1-rc4¹ on May 17, he flagged a documentation update as the highlight. The substance is a policy: the kernel’s security workflow is being restructured to cope with what he called a security list that has become “almost entirely unmanageable.”

The volume problem

#

Two years ago, the kernel’s private security list received two or three reports per week², per Willy Tarreau. It now sees five to ten per day. The same window saw a record flood of CVE growth³: 6,243 new CVEs issued in March alone, 171 of them for the kernel.

Greg Kroah-Hartman has been explicit about the shift⁴:

Months ago, we were getting what we called ‘AI slop,’ AI-generated security reports that were obviously wrong or low quality. It was kind of funny. It didn’t really worry us. […] Something happened a month ago, and the world switched. Now we have real reports.

The findings are real and reproducible. Nicholas Carlini at Anthropic recently used Claude to surface five confirmed kernel vulnerabilities⁵ across NFS, io_uring, futex, and ksmbd — including a heap buffer overflow introduced in 2003 that nobody had found in 23 years. He says he has several hundred more potential crashes he hasn’t had time to manually validate.

What’s actually shipping

#

The revised security-bugs documentation⁶ — authored by Willy Tarreau and merged for 7.1¹ — adds an explicit section on AI-assisted reports. The rule is unambiguous:

If you resorted to AI assistance to identify a bug, you must treat it as public.

The docs also impose prose requirements that read like a checklist of what has been failing: plain text only, no Markdown decorations, summary and critical details first, no “inventing theoretical consequences,” and a reproducer the reporter has actually tested. Failure to follow them, the docs warn plainly, “exposes your report to the risk of being ignored.”

The logic

#

Linus’s frustration is unmistakable — “AI tools are great, but only if they actually help, rather than cause unnecessary pain and pointless make-believe work” — but his rationale for moving AI reports out of the embargo channel is operational, not punitive⁷:

AI detected bugs are pretty much by definition not secret, and treating them on some private list is a waste of time for everybody involved - and only makes that duplication worse because the reporters can’t even see each other’s reports.

When discovery is parallelizable across labs running the same tools against the same code, embargo stops protecting anyone. The kernel’s response is not to throttle the supply but to redirect it: route AI-assisted findings to public channels where duplicates can self-deduplicate, and keep the private list for what embargoes were originally designed to cover.

Kroah-Hartman’s working summary: “For the kernel, we can handle it.” The harder question is what happens to smaller projects with no maintainer pool to expand.