Re: [PATCH v2 2/3] Documentation: security-bugs: explain what is and is not a security bug

[Willy Tarreau]

On Wed, May 06, 2026 at 06:02:15PM +0200, Willy Tarreau wrote:
> Hi Linus,
> 
> On Wed, May 06, 2026 at 08:46:07AM -0700, Linus Torvalds wrote:
> > [ Coming back to this after a week of trying to clean up the disaster
> > that is my inbox after the merge window ]
> > 
> > On Sun, 3 May 2026 at 04:35, Willy Tarreau <w@xxxxxx> wrote:
> > >
> > > The use of automated tools to find bugs in random locations of the kernel
> > > induces a raise of security reports even if most of them should just be
> > > reported as regular bugs. This patch is an attempt at drawing a line
> > > between what qualifies as a security bug and what does not, hoping to
> > > improve the situation and ease decision on the reporter's side.
> > 
> > I actually think we may want to go further than this.
> > 
> > I think we should simply make it a rule that "a 'security' bug that is
> > found by AI is public".
> 
> This would definitely help us a lot on sec@k.o, but...
> 
> > Now, I may be influenced by that "my inbox is a disaster during the
> > merge window" thing, but I do think this is pretty fundamental: if
> > somebody finds a bug with more or less standard AI tools (ie we're not
> > talking magical special hardware and nation-state level efforts), then
> > that bug pretty much by definition IS NOT SECRET.
> 
> I think it's only 99.9% true. I mean, I've used such tools myself to
> find bugs that were not found otherwise and I know that:
>   - interactions with the tools count a lot
>   - luck counts even more

Thinking more about it, there's still something that won't go round:

- people have always been looking for vulnerabilities, sometimes for
  fun, and often to proudly show a CVE on their resume ; we've been
  dealing with that for many years.
- now they can do the same using AI and making much less effort, but
  their approach still stems from actively searching a vulnerability
- when they find something, they're certain it's a vulnerability
  because it's what they asked for (hence the threat model addition).
- if we tell them "don't report this to s@k.o" they will simply send
  them directly to the maintainers, who are even less accustomed to
  the process and will not benefit from the security team's experience
  in triaging nor support in saying "no". And we all know how stressful
  a vulnerability report can be for a developer who instantly has to
  stop doing everything and start to look at it just in case it would
  be valid.

For these reasons I'd rather propose that we say something around these
lines:

    Note that the security team will generally consider AI-assisted
    findings as public and will often ask you to repost your report
    to public lists.

Another point is that for many vulns there are two types of adversaries:
  - criminals
  - script kiddies

The former must be assumed to also have discovered the same vuln, possibly
earlier, and to be actively exploiting it. The latter however, is just
going to use whatever published exploit to say "look mum, I'm root".
Public reports containing too many details will speed up usability for
this group and that's not good for users.

And we *know* that some reports contain working PoC that need very little
modification. Passing them through s@k.o for triaging feels safer than
directing them to public lists with no early validation.

So in short, I think that:
  - AI reports should be considered public, but not necessarily well known
    yet
  - AI reports often contain repros that shouldn't be posted publicly
  - AI reports wording can be intimidating to developers not used to
    receiving these things

 -> the security team should remain the first filtering layer for this
    for new reporters even if it means continuing to see some noise.
    I think that instead it's the 3rd patch about the threat model that
    should help us receive less noise by explaining what is not a
    vulnerability.

I can rework that part a bit to reflect this.

Willy