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

[Greg KH <greg@kroah.com>]

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