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.

Thanks,
Willy

Reply via email to