On Sat, May 09, 2026 at 08:39:37AM +0200, Greg KH wrote:
> On Fri, May 08, 2026 at 06:39:07PM +0200, Willy Tarreau wrote:
> > Greg,
> > 
> > does this addition on top of the current patch address your concerns ?
> > 
> > --- a/Documentation/process/security-bugs.rst
> > +++ b/Documentation/process/security-bugs.rst
> > @@ -88,6 +88,14 @@ can be easily exploited, representing an imminent threat 
> > to many users.  Before
> >  reporting, consider whether the issue actually crosses a trust boundary on 
> > such
> >  a system.
> > 
> > +**If you resorted to AI assistance to identify a bug, you must treat it as
> > +public**. While you may have valid reasons to believe it is not, the 
> > security
> > +team's experience shows that bugs discovered this way systematically 
> > surface
> > +simultaneously across multiple researchers, often on the same day. In this
> > +case, do not publicly share a reproducer, as this could cause unintended 
> > harm;
> > +just mention that one is available and maintainers might ask for it 
> > privately
> > +if they need it.
> > +
> >  If you are unsure whether an issue qualifies, err on the side of reporting
> >  privately: the security team would rather triage a borderline report than 
> > miss
> >  a real vulnerability.  Reporting ordinary bugs to the security list, 
> > however,
> > @@ -102,7 +110,7 @@ affected subsystem's maintainers and Cc: the Linux 
> > kernel security team.  Do
> >  not send it to a public list at this stage, unless you have good reasons to
> >  consider the issue as being public or trivial to discover (e.g. result of a
> >  widely available automated vulnerability scanning tool that can be 
> > repeated by
> > -anyone).
> > +anyone, or use of AI-based tools).
> > 
> >  If you're sending a report for issues affecting multiple parts in the 
> > kernel,
> >  even if they're fairly similar issues, please send individual messages 
> > (think
> > 
> > If so I can resend with it.
> 
> Looks good to me, thanks!

Thank you. I'll integrate Shuah's comments and will send a v3. After
that I'll see if we can better split the public vs private part, because
I'm starting to find it complicated, but I don't want to postpone for
too long if having all of this can already help us.

Willy

Reply via email to