[PATCH 13/14] docs: submitting-patches: defer to security-bugs.rst for security fixes

[Willy Tarreau]

Despite recent improvements, the security team continues to receive
non-compliant reports clearly indicating that the author had not read
the documentation. It turns out that submitting-patches.rst asks to
send such reports to list's address in a short paragraph, so it's very
likely that some reports only find this one and do not read the rest!
Let's replace this with an invitation to read the security doc instead.

Reviewed-by: Greg Kroah-Hartman <gregkh@xxxxxxxxxxxxxxxxxxx>
Signed-off-by: Willy Tarreau <w@xxxxxx>
---
 Documentation/process/submitting-patches.rst | 10 +++++-----
 1 file changed, 5 insertions(+), 5 deletions(-)

diff --git a/Documentation/process/submitting-patches.rst b/Documentation/process/submitting-patches.rst
index f271d7413f72c..ac7d0d8f5be56 100644
--- a/Documentation/process/submitting-patches.rst
+++ b/Documentation/process/submitting-patches.rst
@@ -253,11 +253,11 @@ He gets a lot of e-mail, and, at this point, very few patches go through
 Linus directly, so typically you should do your best to -avoid-
 sending him e-mail.
 
-If you have a patch that fixes an exploitable security bug, send that patch
-to security@xxxxxxxxxx.  For severe bugs, a short embargo may be considered
-to allow distributors to get the patch out to users; in such cases,
-obviously, the patch should not be sent to any public lists. See also
-Documentation/process/security-bugs.rst.
+If you have a patch that fixes a bug with possible security implications, you
+need to read Documentation/process/security-bugs.rst first: it explains which
+bugs need to be handled privately, and whom to send them to.  Most such fixes
+are posted publicly like any other fix, but their reproducers and exploits must
+never be posted publicly.
 
 Patches that fix a severe bug in a released kernel should be directed
 toward the stable maintainers by putting a line like this::
-- 
2.52.0