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! greg k-h
