Maintainer workflows discussions
 help / color / mirror / Atom feed
From: Willy Tarreau <w@1wt.eu>
To: Jonathan Corbet <corbet@lwn.net>
Cc: skhan@linuxfoundation.org, Randy Dunlap <rdunlap@infradead.org>,
	workflows@vger.kernel.org, linux-doc@vger.kernel.org,
	linux-kernel@vger.kernel.org, netdev@vger.kernel.org,
	gregkh@linuxfoundation.org, Johan Hovold <johan@kernel.org>,
	"David S. Miller" <davem@davemloft.net>,
	Eric Dumazet <edumazet@kernel.org>,
	Jakub Kicinski <kuba@kernel.org>, Paolo Abeni <pabeni@redhat.com>,
	Simon Horman <horms@kernel.org>
Subject: [PATCH v2 13/14] docs: submitting-patches: defer to security-bugs.rst for security fixes
Date: Sat, 14 Nov 2026 20:00:13 +0100	[thread overview]
Message-ID: <20261114190014.17826-14-w@1wt.eu> (raw)
In-Reply-To: <20261114190014.17826-1-w@1wt.eu>

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@linuxfoundation.org>
Reviewed-by: Johan Hovold <johan@kernel.org>
Signed-off-by: Willy Tarreau <w@1wt.eu>
---
 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@kernel.org.  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


  parent reply	other threads:[~2026-11-14 19:01 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-11-14 19:00 [PATCH v2 00/14] security-bugs doc updates Willy Tarreau
2026-11-14 19:00 ` [PATCH v2 01/14] docs: security-bugs: reorganize the document without changing its contents Willy Tarreau
2026-11-14 19:00 ` [PATCH v2 02/14] docs: security-bugs: clarify when to Cc the security team Willy Tarreau
2026-11-14 19:00 ` [PATCH v2 03/14] docs: security-bugs: never publish reproducers of bugs with a security impact Willy Tarreau
2026-11-14 19:00 ` [PATCH v2 04/14] docs: threat-model: clarify the case of automatically mounted file systems Willy Tarreau
2026-11-14 19:00 ` [PATCH v2 05/14] docs: security-bugs: explain how to send a fix that can be applied Willy Tarreau
2026-11-14 19:00 ` [PATCH v2 06/14] docs: security-bugs: do not send archives or binary attachments Willy Tarreau
2026-11-14 19:00 ` [PATCH v2 07/14] docs: security-bugs: first-time reporters must send a single report first Willy Tarreau
2026-11-14 19:00 ` [PATCH v2 08/14] docs: security-bugs: explain what to do when a report gets no response Willy Tarreau
2026-11-14 19:00 ` [PATCH v2 09/14] docs: security-bugs: reports left unanswered for 7 days will be dropped Willy Tarreau
2026-11-14 19:00 ` [PATCH v2 10/14] docs: security-bugs: add a section for maintainers receiving reports Willy Tarreau
2026-11-14 19:00 ` [PATCH v2 11/14] docs: security-bugs: explain why directly sent reports add extra work Willy Tarreau
2026-11-14 19:00 ` [PATCH v2 12/14] docs: security-bugs: explain why AI-found bugs are handled publicly Willy Tarreau
2026-11-14 19:00 ` Willy Tarreau [this message]
2026-11-14 19:00 ` [PATCH v2 14/14] docs: netdev: drop references to the securit list in the doc Willy Tarreau

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20261114190014.17826-14-w@1wt.eu \
    --to=w@1wt.eu \
    --cc=corbet@lwn.net \
    --cc=davem@davemloft.net \
    --cc=edumazet@kernel.org \
    --cc=gregkh@linuxfoundation.org \
    --cc=horms@kernel.org \
    --cc=johan@kernel.org \
    --cc=kuba@kernel.org \
    --cc=linux-doc@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=netdev@vger.kernel.org \
    --cc=pabeni@redhat.com \
    --cc=rdunlap@infradead.org \
    --cc=skhan@linuxfoundation.org \
    --cc=workflows@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox