On Fri, May 08, 2026 at 05:35:39PM +0200, Greg KH wrote:
> 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 <[email protected]> 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".
> >
> > 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.
>
> After the past 2 weeks, and the past 2 months, I am going to violently
> agree with you here. We've seen so many "duplicate" bug reports it's
> not funny. All of the modern LLMs are feeding the output back into the
> model for future runs, which makes the data totally public. Even if
> not, the output is being monitored by external companies at the very
> least.
>
> > So why should be consider it special and have it be on the security list?
>
> I don't think we should anymore.
>
> Yes, having a full reproducer in public is not good, but the general
> "this is a bug" comments we should start redirecting to public lists
> more. That's the only way we are going to handle this influx as our
> "normal" bug workflow works very well, especially when it comes with a
> fix, as these LLM tools can provide very easily.
>
> So if this could be reworded somehow to reflect that, maybe?
What I'm trying to do is to make sure the reports don't flood just to
maintainers (some of whom never got a report, and getting an intimidating
one written by an LLM can be really painful). And in parallel we're trying
to limit public reports for non-AI. So I think the split point revolves
to:
- all bugs (AI and non-AI) affecting the threat model are security bugs,
but AI reports must be considered public as others will find them in
parallel (and we do know that pretty well now).
- if non-AI, send to maintainers and Cc: security, send all repros
you can share
- if AI, the report must be considered public so send to maintainers
and Cc: public lists AND always LKML, and never security@, and do
not send the repros publicly.
=> this reinforces the role of security@ to be for triage, coordination
and assitance to maintainers so that they're never left to themselves
(i.e. private [email protected]; public bugs=maint+public list).
Also, I'll add "for AI, please see the points below" (the 3rd patch with
all the rules).
There remains a gray zone with the repros from AI tools (since they're
good at writing them). They should sent to maintainers only (no need to
involve [email protected]) but it requires a second message.
> But the "what is and is not a security bug" is a good thing overall. We
> need a solid definition of our threat model if for no other reason to
> keep me from having to write over and over "Once a driver is bound to
> the kernel, we trust the hardware"...
Over the last two weeks I felt like you needed a macro on your keyboard
that would post a link to that doc in lore!
Thanks,
Willy
