[PATCH 00/14] security-bugs doc updates

[PATCH 00/14] security-bugs doc updates

[Willy Tarreau]

Hi,

Here comes a new batch of updates for the security bugs doc,
essentially to make it more readable and to address some of its
apparent contradictions for those not reading it entirely. Some
additions were made to explain how to send a patch and a reproducer
separately, and to ask that first-time reporters send a single
report at once first.

The first patch looks big, it only reorders paragraphs to fix the
current mess resulting from minimal and incremental updates we've
done over the last 6 months in reactions to some repeated mistakes
found in reports. This accumulation has resulted in certain topics
being discussed in a somewhat inconsistent way at different places
in the document.

Aside this big patch (which only reorders, doesn't change a word,
which can be verified with "git show --color-moved", there are 13
small patches each touching a single paragraph.

Interestingly, I discovered that the list's address was still present
in historic areas of the netdev doc and in submitting-patches, which
could be an explanation for the non-negligible amount of reports we
receive showing proofs that the doc was never read, so I've fixed
that as well.

Thanks!
Willy

--
Willy Tarreau (14):
  docs: security-bugs: reorganize the document without changing its
    contents
  docs: security-bugs: clarify when to Cc the security team
  docs: security-bugs: never publish reproducers of bugs with a security
    impact
  docs: threat-model: clarify the case of automatically mounted file
    systems
  docs: security-bugs: explain how to send a fix that can be applied
  docs: security-bugs: do not send archives or binary attachments
  docs: security-bugs: first-time reporters must send a single report
    first
  docs: security-bugs: explain what to do when a report gets no response
  docs: security-bugs: reports left unanswered for 7 days will be
    dropped
  docs: security-bugs: add a section for maintainers receiving reports
  docs: security-bugs: explain why directly sent reports add extra work
  docs: security-bugs: explain why AI-found bugs are handled publicly
  docs: submitting-patches: defer to security-bugs.rst for security
    fixes
  docs: netdev: align the security fixes section with security-bugs.rst

 Documentation/process/maintainer-netdev.rst  |  13 +-
 Documentation/process/security-bugs.rst      | 410 +++++++++++++------
 Documentation/process/submitting-patches.rst |  10 +-
 Documentation/process/threat-model.rst       |  23 +-
 4 files changed, 310 insertions(+), 146 deletions(-)

-- 
2.52.0

[PATCH 01/14] docs: security-bugs: reorganize the document without changing its contents

[Willy Tarreau]

The document has grown incrementally over time and new rules were added
where they fit at the moment, each time trying to minimize the affected
context in order to ease reviews, resulting in information being spread
over several sections (e.g. the rules about when to Cc the security team
appear in three different places), which makes it hard to follow for
reporters and hard to update. Moreover it probably encourages reporters
to stop reading once they think they found the information they were
looking for.

This patch attempts to reorganize the document to make it both easier to
discover, and to ease future updates. It only moves existing paragraphs,
without changing the wording:
  - we now start with what qualifies as a security bug (important to
    permit the user to stop reading if sufficient);
  - report preparation is now more natural, with responsible use of AI
    just after "preparing your report".
  - "identifying contacts" was split into 1) finding the maintainers,
    and 2) when to Cc the security team, with a part of what was earlier
    in "sending the report" about the Cc rules.
  - the "one message per issue" paragraph was moved to "Sending the
    report";
  - a new section "after sending the report" covers the parapgraph
    about a reporter's expected availability in a more visible way,
    and could later receive parts related to coordinated disclosure
    if relevant.

Using "git show --color-moved=dimmed-zebra" helps here, and shows that
aside section titles, nothing was added nor removed.

Reviewed-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Willy Tarreau <w@1wt.eu>
---
 Documentation/process/security-bugs.rst | 241 ++++++++++++------------
 1 file changed, 125 insertions(+), 116 deletions(-)

diff --git a/Documentation/process/security-bugs.rst b/Documentation/process/security-bugs.rst
index c7dfecc87764c..3575af5274f04 100644
--- a/Documentation/process/security-bugs.rst
+++ b/Documentation/process/security-bugs.rst
@@ -7,6 +7,42 @@ Linux kernel developers take security very seriously.  As such, we'd
 like to know when a security bug is found so that it can be fixed and
 disclosed as quickly as possible.
 
+What qualifies as a security bug
+--------------------------------
+
+It is important that most bugs are handled publicly so as to involve the widest
+possible audience and find the best solution.  By nature, bugs that are handled
+in closed discussions between a small set of participants are less likely to
+produce the best possible fix (e.g., risk of missing valid use cases, limited
+testing abilities).
+
+It turns out that the majority of the bugs reported via the security team are
+just regular bugs that have been improperly qualified as security bugs due to
+a lack of awareness of the Linux kernel's threat model, as described in
+Documentation/process/threat-model.rst, and ought to have been sent through
+the normal channels described in Documentation/admin-guide/reporting-issues.rst
+instead.
+
+The security list exists for urgent bugs that grant an attacker a capability
+they are not supposed to have on a correctly configured production system, and
+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,
+does not make them move faster and consumes triage capacity that other reports
+need.
+
 Preparing your report
 ---------------------
 
@@ -70,107 +106,6 @@ In addition, the following information are highly desirable:
     the issue appear. It is useful to share them, as they can be helpful to
     keep end users protected during the time it takes them to apply the fix.
 
-What qualifies as a security bug
---------------------------------
-
-It is important that most bugs are handled publicly so as to involve the widest
-possible audience and find the best solution.  By nature, bugs that are handled
-in closed discussions between a small set of participants are less likely to
-produce the best possible fix (e.g., risk of missing valid use cases, limited
-testing abilities).
-
-It turns out that the majority of the bugs reported via the security team are
-just regular bugs that have been improperly qualified as security bugs due to
-a lack of awareness of the Linux kernel's threat model, as described in
-Documentation/process/threat-model.rst, and ought to have been sent through
-the normal channels described in Documentation/admin-guide/reporting-issues.rst
-instead.
-
-The security list exists for urgent bugs that grant an attacker a capability
-they are not supposed to have on a correctly configured production system, and
-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,
-does not make them move faster and consumes triage capacity that other reports
-need.
-
-Identifying contacts
---------------------
-
-The most effective way to report a security bug is to send it directly to the
-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, 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
-that maintainers will not all work on the issues at the same time). The only
-exception is when an issue concerns closely related parts maintained by the
-exact same subset of maintainers, and these parts are expected to be fixed all
-at once by the same commit, then it may be acceptable to report them at once.
-
-One difficulty for most first-time reporters is to figure the right list of
-recipients to send a report to.  In the Linux kernel, all official maintainers
-are trusted, so the consequences of accidentally including the wrong maintainer
-are essentially a bit more noise for that person, i.e. nothing dramatic.  As
-such, a suitable method to figure the list of maintainers (which kernel
-security officers use) is to rely on the get_maintainer.pl script, tuned to
-only report maintainers.  This script, when passed a file name, will look for
-its path in the MAINTAINERS file to figure a hierarchical list of relevant
-maintainers.  Calling it a first time with the finest level of filtering will
-most of the time return a short list of this specific file's maintainers::
-
-  $ ./scripts/get_maintainer.pl --no-l --no-r --pattern-depth 1 \
-    drivers/example.c
-  Developer One <dev1@example.com> (maintainer:example driver)
-  Developer Two <dev2@example.org> (maintainer:example driver)
-
-These two maintainers should then receive the message.  If the command does not
-return anything, it means the affected file is part of a wider subsystem, so we
-should be less specific::
-
-  $ ./scripts/get_maintainer.pl --no-l --no-r drivers/example.c
-  Developer One <dev1@example.com> (maintainer:example subsystem)
-  Developer Two <dev2@example.org> (maintainer:example subsystem)
-  Developer Three <dev3@example.com> (maintainer:example subsystem [GENERAL])
-  Developer Four <dev4@example.org> (maintainer:example subsystem [GENERAL])
-
-Here, picking the first, most specific ones, is sufficient.  When the list is
-long, it is possible to produce a comma-delimited e-mail address list on a
-single line suitable for use in the To: field of a mailer like this::
-
-  $ ./scripts/get_maintainer.pl --no-tree --no-l --no-r --no-n --m \
-    --no-git-fallback --no-substatus --no-rolestats --no-multiline \
-    --pattern-depth 1 drivers/example.c
-  dev1@example.com, dev2@example.org
-
-or this for the wider list::
-
-  $ ./scripts/get_maintainer.pl --no-tree --no-l --no-r --no-n --m \
-    --no-git-fallback --no-substatus --no-rolestats --no-multiline \
-    drivers/example.c
-  dev1@example.com, dev2@example.org, dev3@example.com, dev4@example.org
-
-If at this point you're still facing difficulties spotting the right
-maintainers, **and only in this case**, it's possible to send your report to
-the Linux kernel security team only.  Your message will be triaged, and you
-will receive instructions about whom to contact, if needed.  Your message may
-equally be forwarded as-is to the relevant maintainers.
-
 Responsible use of AI to find bugs
 ----------------------------------
 
@@ -239,7 +174,7 @@ identify the maintainers with get_maintainer.pl.
 On top of that procedure, the AI assistant **MUST**:
 
 1. Prepare a plain-text report explaining the problem. It must contain the
-   four items listed at the top of this file as absolutely necessary: the
+   four items listed above as absolutely necessary: the
    affected version or commit ID noted while following the procedure above,
    the description of the problem, the reproducer or its status, and the
    triggering conditions.
@@ -251,22 +186,69 @@ On top of that procedure, the AI assistant **MUST**:
 
 A more detailed process is covered at https://github.com/masoncl/kres.git.
 
-Sending the report
-------------------
+Identifying contacts
+--------------------
 
-Reports are to be sent over e-mail exclusively.  Please use a working e-mail
-address, preferably the same that you want to appear in ``Reported-by`` tags
-if any.  If unsure, send your report to yourself first.
+The most effective way to report a security bug is to send it directly to the
+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, or use of AI-based tools).
 
-The security team and maintainers almost always require additional
-information beyond what was initially provided in a report and rely on
-active and efficient collaboration with the reporter to perform further
-testing (e.g., verifying versions, configuration options, mitigations, or
-patches). Before contacting the security team, the reporter must ensure
-they are available to explain their findings, engage in discussions, and
-run additional tests.  Reports where the reporter does not respond promptly
-or cannot effectively discuss their findings may be abandoned if the
-communication does not quickly improve.
+Finding the maintainers
+~~~~~~~~~~~~~~~~~~~~~~~
+
+One difficulty for most first-time reporters is to figure the right list of
+recipients to send a report to.  In the Linux kernel, all official maintainers
+are trusted, so the consequences of accidentally including the wrong maintainer
+are essentially a bit more noise for that person, i.e. nothing dramatic.  As
+such, a suitable method to figure the list of maintainers (which kernel
+security officers use) is to rely on the get_maintainer.pl script, tuned to
+only report maintainers.  This script, when passed a file name, will look for
+its path in the MAINTAINERS file to figure a hierarchical list of relevant
+maintainers.  Calling it a first time with the finest level of filtering will
+most of the time return a short list of this specific file's maintainers::
+
+  $ ./scripts/get_maintainer.pl --no-l --no-r --pattern-depth 1 \
+    drivers/example.c
+  Developer One <dev1@example.com> (maintainer:example driver)
+  Developer Two <dev2@example.org> (maintainer:example driver)
+
+These two maintainers should then receive the message.  If the command does not
+return anything, it means the affected file is part of a wider subsystem, so we
+should be less specific::
+
+  $ ./scripts/get_maintainer.pl --no-l --no-r drivers/example.c
+  Developer One <dev1@example.com> (maintainer:example subsystem)
+  Developer Two <dev2@example.org> (maintainer:example subsystem)
+  Developer Three <dev3@example.com> (maintainer:example subsystem [GENERAL])
+  Developer Four <dev4@example.org> (maintainer:example subsystem [GENERAL])
+
+Here, picking the first, most specific ones, is sufficient.  When the list is
+long, it is possible to produce a comma-delimited e-mail address list on a
+single line suitable for use in the To: field of a mailer like this::
+
+  $ ./scripts/get_maintainer.pl --no-tree --no-l --no-r --no-n --m \
+    --no-git-fallback --no-substatus --no-rolestats --no-multiline \
+    --pattern-depth 1 drivers/example.c
+  dev1@example.com, dev2@example.org
+
+or this for the wider list::
+
+  $ ./scripts/get_maintainer.pl --no-tree --no-l --no-r --no-n --m \
+    --no-git-fallback --no-substatus --no-rolestats --no-multiline \
+    drivers/example.c
+  dev1@example.com, dev2@example.org, dev3@example.com, dev4@example.org
+
+If at this point you're still facing difficulties spotting the right
+maintainers, **and only in this case**, it's possible to send your report to
+the Linux kernel security team only.  Your message will be triaged, and you
+will receive instructions about whom to contact, if needed.  Your message may
+equally be forwarded as-is to the relevant maintainers.
+
+Copying the security team
+~~~~~~~~~~~~~~~~~~~~~~~~~
 
 The report must be sent to maintainers.  If there are two or fewer
 recipients in your message, you must also always Cc: the Linux kernel
@@ -283,6 +265,20 @@ who will help verify the bug report and assist developers working on a fix.
 It is possible that the security team will bring in extra help from area
 maintainers to understand and fix the security vulnerability.
 
+Sending the report
+------------------
+
+Reports are to be sent over e-mail exclusively.  Please use a working e-mail
+address, preferably the same that you want to appear in ``Reported-by`` tags
+if any.  If unsure, send your report to yourself first.
+
+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
+that maintainers will not all work on the issues at the same time). The only
+exception is when an issue concerns closely related parts maintained by the
+exact same subset of maintainers, and these parts are expected to be fixed all
+at once by the same commit, then it may be acceptable to report them at once.
+
 Please send **plain text** emails without attachments where possible.
 It is much harder to have a context-quoted discussion about a complex
 issue if all the details are hidden away in attachments.  Think of it like a
@@ -296,6 +292,19 @@ security report. Note that some mailers tend to mangle formatting of plain
 text by default, please consult Documentation/process/email-clients.rst for
 more info.
 
+After sending the report
+------------------------
+
+The security team and maintainers almost always require additional
+information beyond what was initially provided in a report and rely on
+active and efficient collaboration with the reporter to perform further
+testing (e.g., verifying versions, configuration options, mitigations, or
+patches). Before contacting the security team, the reporter must ensure
+they are available to explain their findings, engage in discussions, and
+run additional tests.  Reports where the reporter does not respond promptly
+or cannot effectively discuss their findings may be abandoned if the
+communication does not quickly improve.
+
 Disclosure and embargoed information
 ------------------------------------
 
-- 
2.52.0

[PATCH 02/14] docs: security-bugs: clarify when to Cc the security team

[Willy Tarreau]

The rules indicating when to Cc the security team were a bit confusing,
because "Identifying contacts" said to always Cc it, while the details
said it was only needed for small teams or for the first few reports,
and nothing said what to do when the impact is unclear or when posting
to a public list.

Let's try to clarify this a little bit now that the rules have evolved
a few times, while not changing what already works fine nor from what
is being properly practiced. It also clarifies the "within a week" by
insisting not to ask before that delay.

This patch changes the unconditional Cc at the top to "when needed, see
below", and groups all cases in a single list that's easier to verify
for the reporter.

Reviewed-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Willy Tarreau <w@1wt.eu>
---
 Documentation/process/security-bugs.rst | 49 ++++++++++++++++++-------
 1 file changed, 35 insertions(+), 14 deletions(-)

diff --git a/Documentation/process/security-bugs.rst b/Documentation/process/security-bugs.rst
index 3575af5274f04..1288effcbca79 100644
--- a/Documentation/process/security-bugs.rst
+++ b/Documentation/process/security-bugs.rst
@@ -190,11 +190,11 @@ Identifying contacts
 --------------------
 
 The most effective way to report a security bug is to send it directly to the
-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, or use of AI-based tools).
+affected subsystem's maintainers, and to Cc: the Linux kernel security team
+when needed (see below).  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, or use of AI-based tools).
 
 Finding the maintainers
 ~~~~~~~~~~~~~~~~~~~~~~~
@@ -250,15 +250,36 @@ equally be forwarded as-is to the relevant maintainers.
 Copying the security team
 ~~~~~~~~~~~~~~~~~~~~~~~~~
 
-The report must be sent to maintainers.  If there are two or fewer
-recipients in your message, you must also always Cc: the Linux kernel
-security team who will ensure the message is delivered to the proper
-people, and will be able to assist small maintainer teams with processes
-they may not be familiar with.  For larger teams, Cc: the Linux kernel
-security team for your first few reports or when seeking specific help,
-such as when resending a message which got no response within a week.
-Once you have become comfortable with the process for a few reports, it is
-no longer necessary to Cc: the security list when sending to large teams.
+The report must be sent to maintainers.  You must also Cc: the Linux kernel
+security team in any of the following cases:
+
+  * it is your first report: many first reports are incomplete, too long, too
+    strong, difficult to handle, and put a lot of pressure on maintainers. The
+    security team will help with the process and with the qualification of the
+    issue. Note that this rule also applies if you were asked to fix or adjust
+    a previous submission;
+
+  * there are two or fewer maintainers among the recipients: the security
+    team will ensure the message is delivered to the proper people, and
+    will be able to assist small maintainer teams with processes they may
+    not be familiar with;
+
+  * the maintainers could not be clearly identified (see above);
+
+  * the impact of the issue is uncertain and needs to be qualified. In this
+    case, your must clearly state upfront that you are seeking help to qualify
+    this impact, and you will need to share any information you have;
+
+  * you are seeking specific help, such as when resending a message which got
+    no response within a week (and please do not ask for feedback before such
+    a delay, some subsystems have a long report queue, and some maintainers can
+    only read them on spare time).
+
+In other cases, i.e. when a report of clear impact is sent to a larger
+team of clearly identified maintainers, it is not necessary to Cc: the
+security list.  Never Cc: the security list on a message sent to a public
+list.
+
 The Linux kernel security team can be contacted by email at
 <security@kernel.org>.  This is a private list of security officers
 who will help verify the bug report and assist developers working on a fix.
-- 
2.52.0

[PATCH 03/14] docs: security-bugs: never publish reproducers of bugs with a security impact

[Willy Tarreau]

Some bugs are outside the threat model because their exploitation
requires very specific conditions (dedicated network link, crafted
device, crafted file system image only root may mount), but they may
still have a security impact for a few users, and a CVE may be assigned
later. These are handled publicly as regular bugs, but their reproducers
and exploits must never be shared on public lists since that could put
the few exposed users at risk.

The documentation was never very clear about this and a few reporters
were put in embarrassing situations while trying to follow the process,
because threat-model says to check reporting-issues which asks for public
repros. There shouldn't be any ambiguity because reporters reading these
files already come with the idea of reporting a security issue.

Let's clarify this point in threat-model.rst and point to this from
security-bugs.rst.

Reviewed-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Willy Tarreau <w@1wt.eu>
---
 Documentation/process/security-bugs.rst | 14 +++++++++-----
 Documentation/process/threat-model.rst  | 16 +++++++++++++++-
 2 files changed, 24 insertions(+), 6 deletions(-)

diff --git a/Documentation/process/security-bugs.rst b/Documentation/process/security-bugs.rst
index 1288effcbca79..43e5ed737dbc4 100644
--- a/Documentation/process/security-bugs.rst
+++ b/Documentation/process/security-bugs.rst
@@ -21,7 +21,9 @@ just regular bugs that have been improperly qualified as security bugs due to
 a lack of awareness of the Linux kernel's threat model, as described in
 Documentation/process/threat-model.rst, and ought to have been sent through
 the normal channels described in Documentation/admin-guide/reporting-issues.rst
-instead.
+instead. Note that when such a bug may still have a security impact for some
+users, its reproducer and any exploit must never be posted publicly; only the
+fix is (see Documentation/process/threat-model.rst).
 
 The security list exists for urgent bugs that grant an attacker a capability
 they are not supposed to have on a correctly configured production system, and
@@ -142,8 +144,8 @@ handle:
     Please always ensure your tool provides one and **test it thoroughly**. If
     the reproducer does not work, or if the tool cannot produce one, the
     validity of the report should be seriously questioned. Note that since the
-    report will be posted to a public list, the reproducer should only be
-    shared upon maintainers' request.
+    report will be posted to a public list, the reproducer must only be
+    shared privately with the maintainers.
 
   * **Propose a Fix**: Many AI tools are actually better at writing code than
     evaluating it. Please ask your tool to propose a fix and **test it** before
@@ -162,7 +164,7 @@ likely that usage has declined and exposed users are virtually non-existent
 (e.g., drivers for very old hardware, obsolete filesystems). In such cases,
 there is no need to consume a maintainer's time with an unimportant report. If
 the issue is clearly trivial and publicly discoverable, you should report it
-directly to the public mailing lists.
+directly to the public mailing lists, without the reproducer.
 
 At the very least, when using an AI assistant to find and report bugs, make the
 assistant read this file and threat-model.rst before proceeding, and have it
@@ -194,7 +196,9 @@ affected subsystem's maintainers, and to Cc: the Linux kernel security team
 when needed (see below).  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, or use of AI-based tools).
+scanning tool that can be repeated by anyone, or use of AI-based tools).  Even
+in this case, never post a reproducer or an exploit to a public list; only
+maintainers need it, and publishing it could put some users in trouble.
 
 Finding the maintainers
 ~~~~~~~~~~~~~~~~~~~~~~~
diff --git a/Documentation/process/threat-model.rst b/Documentation/process/threat-model.rst
index 04e5df6a6f78b..72cb36dd383d6 100644
--- a/Documentation/process/threat-model.rst
+++ b/Documentation/process/threat-model.rst
@@ -105,7 +105,21 @@ In the Linux kernel's threat model, the following classes of problems are
 **NOT** considered Linux Kernel vulnerabilities. However, when it is believed
 that the kernel could do better, they should be reported, so that they can be
 reviewed and fixed where reasonably possible, but they will be handled as any
-regular bug:
+regular bug.
+
+Some of these bugs may still have a security impact for a few users, for
+example when their exploitation requires a dedicated network link, a crafted
+device, or a crafted file system image that only root may mount. For the vast
+majority of users the impact is null, and such isolated bugs do not represent a
+target worth writing an exploit for, which is why they are handled publicly
+(a CVE may still be assigned later by the :doc:`CVE team <cve>`). However,
+publishing a reproducer or an exploit could put the few exposed users at risk.
+For such bugs, the fix is sent publicly like any regular fix, with a commit
+message that does not detail how to exploit the bug, while the reproducer and
+any exploit are only shared privately with the maintainers and are never posted
+to public lists.
+
+The following classes of problems are not considered as vulnerabilities:
 
 * **Configuration**:
 
-- 
2.52.0

[PATCH 04/14] docs: threat-model: clarify the case of automatically mounted file systems

[Willy Tarreau]

Bugs triggered by crafted file system images are among the most
frequently reported non-security issues, often with the argument that
some desktop environments automatically mount removable media without
checking them.

Let's state that automatic mounting of unchecked file systems does not
change the analysis: an automounter is expected to check a file system
before mounting it, otherwise it is at fault, and if the check does not
detect the issue, the file system checker is at fault (this doesn't void
the need to handle the kernel side of the report). Fixes should then be
directed to these tools. The only exception remains drivers specifically
documented as being hardened against hostile inputs, as already stated
for non-conforming devices and media.

Reviewed-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Willy Tarreau <w@1wt.eu>
---
 Documentation/process/threat-model.rst | 7 ++++++-
 1 file changed, 6 insertions(+), 1 deletion(-)

diff --git a/Documentation/process/threat-model.rst b/Documentation/process/threat-model.rst
index 72cb36dd383d6..b82d5d168b4c3 100644
--- a/Documentation/process/threat-model.rst
+++ b/Documentation/process/threat-model.rst
@@ -234,7 +234,12 @@ The following classes of problems are not considered as vulnerabilities:
     image: mounting a block device is a privileged operation (see above), and
     the administrator is responsible for the media they mount. This includes
     issues that are resolved, mitigated, or detected by running a filesystem
-    consistency check (fsck) on the image prior to mounting.
+    consistency check (fsck) on the image prior to mounting. Automatic
+    mounting of unchecked file systems (e.g. removable media mounted by a
+    desktop environment) does not change this: an automounter is expected to
+    check a file system before mounting it, otherwise it is at fault, and if
+    the check does not detect the issue, the file system checker is at fault.
+    In such cases, fixes should be directed to these tools.
 
   * bugs whose reproduction requires hardware modification or emulation,
     including fake USB devices that pretend to be another one, or devices
-- 
2.52.0

[PATCH 05/14] docs: security-bugs: explain how to send a fix that can be applied

[Willy Tarreau]

Most fixes accompanying security reports cannot be applied with git am,
either because they were damaged by the mailer, or because they just
lack a commit message, and the vast majority of our responses to
reporters are about the patch format. The doc only said to format the
fix "in a way that can be immediately merged", but by now it has
become clear that for many reporters it doesn't have the same meaning
as for maintainers.

Let's give concrete methods: preferably the report as the cover letter
of the series produced by git format-patch, then the fix sent as a reply
to the report, and as a last resort the patch attached, with a warning
that some maintainers won't look at it. Let's also explain how to deal
with public patches and private reports.

Reviewed-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Willy Tarreau <w@1wt.eu>
---
 Documentation/process/security-bugs.rst | 46 +++++++++++++++++++++++--
 1 file changed, 44 insertions(+), 2 deletions(-)

diff --git a/Documentation/process/security-bugs.rst b/Documentation/process/security-bugs.rst
index 43e5ed737dbc4..e0fb7058a999e 100644
--- a/Documentation/process/security-bugs.rst
+++ b/Documentation/process/security-bugs.rst
@@ -308,8 +308,9 @@ Please send **plain text** emails without attachments where possible.
 It is much harder to have a context-quoted discussion about a complex
 issue if all the details are hidden away in attachments.  Think of it like a
 :doc:`regular patch submission <../process/submitting-patches>`
-(even if you don't have a patch yet): describe the problem and impact, list
-reproduction steps, and follow it with a proposed fix, all in plain text.
+(even if you don't have a patch yet): describe the problem and impact, and
+list reproduction steps, all in plain text, then provide a proposed fix as
+described below.
 Markdown, HTML and RST formatted reports are particularly frowned upon since
 they're quite hard to read for humans and encourage to use dedicated viewers,
 sometimes online, which by definition is not acceptable for a confidential
@@ -317,6 +318,47 @@ security report. Note that some mailers tend to mangle formatting of plain
 text by default, please consult Documentation/process/email-clients.rst for
 more info.
 
+Sending a fix
+~~~~~~~~~~~~~
+
+Most fixes sent along with reports cannot be applied as-is, because they were
+damaged by the mailer or lacking a commit message, forcing maintainers to ask
+for a resend. A fix must be applicable using ``git am``, which is most easily
+achieved by letting git produce and send the messages (see
+Documentation/process/submitting-patches.rst).
+
+When the fix is meant to only be sent privately, the preferred method is to
+send the report as a cover letter of a series, followed by the fix::
+
+  $ git format-patch --cover-letter -1
+  (edit 0000-cover-letter.patch and replace the subject and text with the
+   report's subject and text)
+  $ git send-email --suppress-cc=all --to=<maintainers> 000*.patch
+
+The recipients are those determined above (add ``--cc=`` for the security team
+when needed). The ``--suppress-cc=all`` option is important: without it,
+``git send-email`` also sends the messages to addresses found in the patch's
+tags (e.g. ``Cc: stable@vger.kernel.org``), which would leak the report to a
+public list.
+
+If the report was already sent, the fix may be sent as a reply to it, to the
+same recipients, for example using ``git send-email --suppress-cc=all
+--in-reply-to=<report's Message-ID>``. As a last resort, when none of these
+methods is possible, the file produced by ``git format-patch`` may be attached
+as-is to the report, but be aware that some maintainers will not look at
+attachments. However, never attach more than one patch per message without
+being explicitly invited to so, as this would significantly complicate reviews.
+
+When the fix is meant to be public (e.g. for bugs found using AI-based tools,
+see above), send it using ``git send-email`` to the maintainers and lists
+reported by get_maintainer.pl (i.e. without the ``--no-l`` option), with a
+commit message that does not detail how to exploit the bug. Then send the
+report and the reproducer privately to the maintainers (and to the security
+team when needed), mentioning the patch's Message-ID or its link on
+https://lore.kernel.org/ so that they can be matched. The report may also be
+sent as a reply to the public message, after carefully removing all public
+addresses from the To: and Cc: fields.
+
 After sending the report
 ------------------------
 
-- 
2.52.0

[PATCH 06/14] docs: security-bugs: do not send archives or binary attachments

[Willy Tarreau]

Many reports still come with zip files or other archives attached, which
are a pain to deal with, may be blocked by filtering on some maintainers'
end, and that also encourage recipients to adopt risky practices of
opening binary files. The doc only used to say to avoid attachments
"where possible".

Let's clarify that archives, binary files and documents are never
acceptable, that large reproducers should be attached as plain text
source files, and that scripts generating the required files (e.g. file
system images) are a better solution.

Reviewed-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Willy Tarreau <w@1wt.eu>
---
 Documentation/process/security-bugs.rst | 6 +++++-
 1 file changed, 5 insertions(+), 1 deletion(-)

diff --git a/Documentation/process/security-bugs.rst b/Documentation/process/security-bugs.rst
index e0fb7058a999e..ac4409d3b27b2 100644
--- a/Documentation/process/security-bugs.rst
+++ b/Documentation/process/security-bugs.rst
@@ -306,7 +306,11 @@ at once by the same commit, then it may be acceptable to report them at once.
 
 Please send **plain text** emails without attachments where possible.
 It is much harder to have a context-quoted discussion about a complex
-issue if all the details are hidden away in attachments.  Think of it like a
+issue if all the details are hidden away in attachments. Archives (zip, tar,
+etc.), binary files and documents (PDF, etc.) are never acceptable: when a
+reproducer is too large to be placed in the message, attach its source files
+as plain text, and provide scripts that generate the required files (e.g. file
+system images) instead of the files themselves. Think of it like a
 :doc:`regular patch submission <../process/submitting-patches>`
 (even if you don't have a patch yet): describe the problem and impact, and
 list reproduction steps, all in plain text, then provide a proposed fix as
-- 
2.52.0

[PATCH 07/14] docs: security-bugs: first-time reporters must send a single report first

[Willy Tarreau]

The security team regularly receives series of reports from first-time
reporters, all of them suffering from the same issues (missing fix,
wrong format, missing information), which need to be addressed one at a
time and put unneeded pressure on maintainers. Worse, the security team
ends up having to respond to each one of these messages so that CCed
maintainers know about the problem.

Let's ask first-time reporters to send only one report, and to wait for
confirmation that it is in the expected form before sending the other
ones. Also make it clear that violating this rule shows that the
reporter did not read the doc, and that such reporters should be
prepared not to receive any response.

Reviewed-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Willy Tarreau <w@1wt.eu>
---
 Documentation/process/security-bugs.rst | 9 +++++++++
 1 file changed, 9 insertions(+)

diff --git a/Documentation/process/security-bugs.rst b/Documentation/process/security-bugs.rst
index ac4409d3b27b2..6f5b5e492ed3d 100644
--- a/Documentation/process/security-bugs.rst
+++ b/Documentation/process/security-bugs.rst
@@ -304,6 +304,15 @@ exception is when an issue concerns closely related parts maintained by the
 exact same subset of maintainers, and these parts are expected to be fixed all
 at once by the same commit, then it may be acceptable to report them at once.
 
+If this is your first report, send only one, and wait for confirmation that it
+is in the expected form before sending the other ones as individual messages.
+The vast majority of first reports need to be adjusted, and otherwise the same
+mistakes are repeated in all of them, putting needless pressure on the
+maintainers and on the security team.  Violating this rule is a clear
+indication that the reporter did not read this document, and such reporters
+should be prepared not to receive any response at all, as maintainers and the
+security team have better things to do than to repeat what is written here.
+
 Please send **plain text** emails without attachments where possible.
 It is much harder to have a context-quoted discussion about a complex
 issue if all the details are hidden away in attachments. Archives (zip, tar,
-- 
2.52.0

[PATCH 08/14] docs: security-bugs: explain what to do when a report gets no response

[Willy Tarreau]

Some reports get lost, especially those with attachments or HTML, and
reporters sometimes wait for weeks for a response that will never come.
Since reports are private, the reporter has no other way to know if the
report was delivered than asking. The doc only mentioned resending a
message with no response within a week, in the middle of the rules
about copying the security team.

Let's explain it in "After sending the report": wait for a week, since
some maintainers are overloaded or only work in their spare time, then
resend the report with the security team in Cc. Also suggest to drop
any attachment and double-check the output format.

Reviewed-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Willy Tarreau <w@1wt.eu>
---
 Documentation/process/security-bugs.rst | 17 ++++++++++++++---
 1 file changed, 14 insertions(+), 3 deletions(-)

diff --git a/Documentation/process/security-bugs.rst b/Documentation/process/security-bugs.rst
index 6f5b5e492ed3d..11c385630855e 100644
--- a/Documentation/process/security-bugs.rst
+++ b/Documentation/process/security-bugs.rst
@@ -275,9 +275,7 @@ security team in any of the following cases:
     this impact, and you will need to share any information you have;
 
   * you are seeking specific help, such as when resending a message which got
-    no response within a week (and please do not ask for feedback before such
-    a delay, some subsystems have a long report queue, and some maintainers can
-    only read them on spare time).
+    no response within a week (see "After sending the report").
 
 In other cases, i.e. when a report of clear impact is sent to a larger
 team of clearly identified maintainers, it is not necessary to Cc: the
@@ -385,6 +383,19 @@ run additional tests.  Reports where the reporter does not respond promptly
 or cannot effectively discuss their findings may be abandoned if the
 communication does not quickly improve.
 
+Messages sometimes get lost, especially those containing attachments or HTML.
+Since the report is private, you have no other way to know whether it was
+delivered than to ask. However, some subsystems have a long report queue, some
+maintainers are overloaded or only work in their spare time, so please wait for
+a week without any response before resending your report with the security team
+in Cc: (see above). In this case, be clear about the fact that it is a resend,
+and if possible, provide a reference to the original message. Better double
+check that the message is sent in plain text, and drop any attachment when
+resending, to increase the chances of successful delivery. In any case, please
+do not ask for proper receipt before this delay. This will not make your report
+be processed faster, will add extra load on maintainers and all you risk is
+your future messages being ignored.
+
 Disclosure and embargoed information
 ------------------------------------
 
-- 
2.52.0

[PATCH 09/14] docs: security-bugs: reports left unanswered for 7 days will be dropped

[Willy Tarreau]

Between 5 and 10% of the questions or requests sent by the security
team or maintainers to reporters never receive any response. The doc
only said that such reports "may be abandoned", without any indication
of time, and team members keep collection of unresponded threads in
their boxes just due to this.

Let's say that reports for which requests remain unanswered for 7 days
will most likely be dropped. This matches the maximum embargo duration,
which is how long the security team considers it reasonable to keep an
issue private. Also remind that concurrent reports may cause the same
bug to be addressed by someone else who will then receive the credit
in this case.

Reviewed-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Willy Tarreau <w@1wt.eu>
---
 Documentation/process/security-bugs.rst | 8 ++++++++
 1 file changed, 8 insertions(+)

diff --git a/Documentation/process/security-bugs.rst b/Documentation/process/security-bugs.rst
index 11c385630855e..f19c712bc8e7b 100644
--- a/Documentation/process/security-bugs.rst
+++ b/Documentation/process/security-bugs.rst
@@ -383,6 +383,14 @@ run additional tests.  Reports where the reporter does not respond promptly
 or cannot effectively discuss their findings may be abandoned if the
 communication does not quickly improve.
 
+In practice, a report for which questions or requests from the security team
+or the maintainers remain unanswered for 7 days will most likely be dropped.
+This matches the maximum embargo duration described below, which is how long
+the security team considers it reasonable to keep an issue private.  Given the
+number of reports handled in parallel, the same bug may also end up being fixed
+later after being reported by someone else, in which case credit can no longer
+be guaranteed.
+
 Messages sometimes get lost, especially those containing attachments or HTML.
 Since the report is private, you have no other way to know whether it was
 delivered than to ask. However, some subsystems have a long report queue, some
-- 
2.52.0

[PATCH 10/14] docs: security-bugs: add a section for maintainers receiving reports

[Willy Tarreau]

Now that reports are expected to be more commonly sent directly to
maintainers, some of them will receive security reports for the first
time and may not know what to do with them, or worry about having to
deal with them alone.

Let's add a short section reminding them that they are not alone, and
that they are welcome to ask the security team for help at any time.

Reviewed-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Willy Tarreau <w@1wt.eu>
---
 Documentation/process/security-bugs.rst | 21 ++++++++++++++++++++-
 1 file changed, 20 insertions(+), 1 deletion(-)

diff --git a/Documentation/process/security-bugs.rst b/Documentation/process/security-bugs.rst
index f19c712bc8e7b..280f7f3a94603 100644
--- a/Documentation/process/security-bugs.rst
+++ b/Documentation/process/security-bugs.rst
@@ -5,7 +5,8 @@ Security bugs
 
 Linux kernel developers take security very seriously.  As such, we'd
 like to know when a security bug is found so that it can be fixed and
-disclosed as quickly as possible.
+disclosed as quickly as possible. If you are a maintainer and received
+a report, there is a section dedicated to you below.
 
 What qualifies as a security bug
 --------------------------------
@@ -404,6 +405,24 @@ do not ask for proper receipt before this delay. This will not make your report
 be processed faster, will add extra load on maintainers and all you risk is
 your future messages being ignored.
 
+For maintainers receiving a report
+----------------------------------
+
+If you maintain some code in the kernel and received a security report, don't
+panic, you're not alone! The wording of AI-generated reports these days tends
+to sound scary, but just stick to technical facts and proceed like you would
+with any other bug report. Feel free to share the report with other maintainers
+who you think can help you, telling them upfront that the report is private.
+Many other reports are being handled by other maintainers at any instant, do
+not start to worry that the security of the whole kernel suddenly depends on
+your ability to provide a quick fix. Do not let reporters dictate conditions
+that are not compatible with what this document describes. If you have any
+question or doubt, be it about the validity of the report, its impact, the
+process to follow, difficult interactions with a reporter, or even if you've
+mistakenly leaked part of the report to a public list (yes, this happens), just
+ask the security team for help, for example by replying to the report with the
+security team in Cc:, or by forwarding it to them if you're seeking advice.
+
 Disclosure and embargoed information
 ------------------------------------
 
-- 
2.52.0

[PATCH 11/14] docs: security-bugs: explain why directly sent reports add extra work

[Willy Tarreau]

Many reporters imagine that contacting a maintainer directly will bring
their report a special attention but it's exactly the opposite because
it breaks the normal workflow, and deprives the maintainer from their
usual tools (CI, reviews etc), and even requires extra care (e.g. use
separate branches, avoid CCing stable etc). Let's just explain this
upfront so that reporters understand that there is a reason for everyone
insisting on public posts.

Reviewed-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Willy Tarreau <w@1wt.eu>
---
 Documentation/process/security-bugs.rst | 9 ++++++++-
 1 file changed, 8 insertions(+), 1 deletion(-)

diff --git a/Documentation/process/security-bugs.rst b/Documentation/process/security-bugs.rst
index 280f7f3a94603..69dbc47f54625 100644
--- a/Documentation/process/security-bugs.rst
+++ b/Documentation/process/security-bugs.rst
@@ -15,7 +15,14 @@ It is important that most bugs are handled publicly so as to involve the widest
 possible audience and find the best solution.  By nature, bugs that are handled
 in closed discussions between a small set of participants are less likely to
 produce the best possible fix (e.g., risk of missing valid use cases, limited
-testing abilities).
+testing abilities). In addition, dealing with private discussions on patches
+adds much more burden to maintainers who cannot follow their usual process nor
+benefit from their usual tools. For example, many subsystems have CI jobs
+running on publicly posted patches and will not merge a fix before it has been
+validated, and automated review tools such as Sashiko review patches posted to
+the lists. Since the fix will have to be posted publicly anyway, sending it
+privately first only delays it by the time needed to ask for it to be reposted
+publicly, adds extra work, and loses the benefit of early reviews.
 
 It turns out that the majority of the bugs reported via the security team are
 just regular bugs that have been improperly qualified as security bugs due to
-- 
2.52.0

[PATCH 12/14] docs: security-bugs: explain why AI-found bugs are handled publicly

[Willy Tarreau]

Many reporters of bugs found using AI do not follow the instructions to
treat them as public, likely because they're worried to be blamed for
disclosing it.

The security team constantly receives duplicate reports within a very
short time, which makes it clear that when an LLM finds a bug, others
find it at the same time, and some may already be working on exploiting
it. Keeping it private then protects nobody, while handling it publicly
lets everyone fix it quickly without a needless embargo.

Let's clarify these points and also reword a sentence about AI reports
that could be read as "do not send them to us".

Reviewed-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Willy Tarreau <w@1wt.eu>
---
 Documentation/process/security-bugs.rst | 22 ++++++++++++++--------
 1 file changed, 14 insertions(+), 8 deletions(-)

diff --git a/Documentation/process/security-bugs.rst b/Documentation/process/security-bugs.rst
index 69dbc47f54625..72f9b8e45052e 100644
--- a/Documentation/process/security-bugs.rst
+++ b/Documentation/process/security-bugs.rst
@@ -42,10 +42,16 @@ 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.
+simultaneously across multiple researchers, often on the same day. Others are
+then likely to be already working on exploiting the same bug, so keeping it
+private would protect nobody, while handling it publicly lets everyone fix it
+quickly without wasting time in a needless embargo. This applies even when the
+bug falls within the threat model: only the fix and its description are made
+public, and reporters following this procedure will never be blamed for it. In
+any 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, or better, send it upfront in a separate message to
+maintainers only.
 
 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
@@ -169,10 +175,10 @@ ignored.
 Use common sense when evaluating the report. If the affected file has not been
 touched for more than one year and is maintained by a single individual, it is
 likely that usage has declined and exposed users are virtually non-existent
-(e.g., drivers for very old hardware, obsolete filesystems). In such cases,
-there is no need to consume a maintainer's time with an unimportant report. If
-the issue is clearly trivial and publicly discoverable, you should report it
-directly to the public mailing lists, without the reproducer.
+(e.g., drivers for very old hardware, obsolete filesystems). In such cases, as
+well as when the issue is clearly trivial and publicly discoverable, there is
+no need to consume a maintainer's time with a private security report: just
+send the fix publicly like any regular bug fix, without the reproducer.
 
 At the very least, when using an AI assistant to find and report bugs, make the
 assistant read this file and threat-model.rst before proceeding, and have it
-- 
2.52.0

[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@linuxfoundation.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

[PATCH 14/14] docs: netdev: align the security fixes section with security-bugs.rst

[Willy Tarreau]

The netdev maintainer profile asks reporters of bugs with possible
security implications to use the public lists, which is consistent with
the way most of these bugs are handled, but it says nothing about
reproducers, and its suggested alternatives contradict security-bugs.rst:
it points to the security team's address, and to the linux-distros list
which must not be contacted before a fix is accepted. This text has been
left unchanged since 2013 when security reports were not yet a problem,
just because it remained unnoticed during the security doc refactoring.

Let's not change the rule (list first), just remind that repros are not
meant to be publicly shared, and suggest to defer to security-bugs.rst
now.

Reviewed-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Willy Tarreau <w@1wt.eu>
---
 Documentation/process/maintainer-netdev.rst | 13 +++++++++----
 1 file changed, 9 insertions(+), 4 deletions(-)

diff --git a/Documentation/process/maintainer-netdev.rst b/Documentation/process/maintainer-netdev.rst
index 0c155adccfac9..2d1be16c498ec 100644
--- a/Documentation/process/maintainer-netdev.rst
+++ b/Documentation/process/maintainer-netdev.rst
@@ -334,10 +334,15 @@ Security fixes
 Do not email netdev maintainers directly if you think you discovered
 a bug that might have possible security implications.
 The current netdev maintainer has consistently requested that
-people use the mailing lists and not reach out directly.  If you aren't
-OK with that, then perhaps consider mailing security@kernel.org or
-reading about http://oss-security.openwall.org/wiki/mailing-lists/distros
-as possible alternative mechanisms.
+people use the mailing lists and not reach out directly. Fixes for such
+bugs are posted to the lists like any other fix, with a commit message
+that does not detail how to exploit the bug. Never post reproducers or
+exploits publicly: maintainers will ask for them privately if needed.
+
+Only for the rare bugs that constitute a vulnerability according to
+Documentation/process/threat-model.rst and that were not found using
+AI-based tools, follow the process described in
+Documentation/process/security-bugs.rst instead.
 
 
 Co-posting changes to user space components
-- 
2.52.0

Re: [PATCH 14/14] docs: netdev: align the security fixes section with security-bugs.rst

[Jakub Kicinski]

On Mon,  9 Nov 2026 09:02:40 +0100 Willy Tarreau wrote:
> -people use the mailing lists and not reach out directly.  If you aren't
> -OK with that, then perhaps consider mailing security@kernel.org or
> -reading about http://oss-security.openwall.org/wiki/mailing-lists/distros
> -as possible alternative mechanisms.
> +people use the mailing lists and not reach out directly. Fixes for such
> +bugs are posted to the lists like any other fix, with a commit message
> +that does not detail how to exploit the bug. Never post reproducers or
> +exploits publicly: maintainers will ask for them privately if needed.

Please don't insert the wording about not sharing details.
Vast majority of the bugs have no real life security impact
and we have to keep asking people to share the repro.

Can we instead add a brief "please follow the standard process
described in the $security doc" ? Or, maybe even better, can we
delete the "security fixes" section completely? it is very old.

Re: [PATCH 14/14] docs: netdev: align the security fixes section with security-bugs.rst

[Willy Tarreau]

Hi Jakub,

On Mon, Nov 09, 2026 at 08:00:36AM -0800, Jakub Kicinski wrote:
> On Mon,  9 Nov 2026 09:02:40 +0100 Willy Tarreau wrote:
> > -people use the mailing lists and not reach out directly.  If you aren't
> > -OK with that, then perhaps consider mailing security@kernel.org or
> > -reading about http://oss-security.openwall.org/wiki/mailing-lists/distros
> > -as possible alternative mechanisms.
> > +people use the mailing lists and not reach out directly. Fixes for such
> > +bugs are posted to the lists like any other fix, with a commit message
> > +that does not detail how to exploit the bug. Never post reproducers or
> > +exploits publicly: maintainers will ask for them privately if needed.
> 
> Please don't insert the wording about not sharing details.
> Vast majority of the bugs have no real life security impact
> and we have to keep asking people to share the repro.

OK.

> Can we instead add a brief "please follow the standard process
> described in the $security doc" ? Or, maybe even better, can we
> delete the "security fixes" section completely? it is very old.

Oh yes that would be even better indeed! I'll send a v2 of this one
ASAP.

thanks!
Willy