[PATCH 0/3] Documentation: security-bugs: new updates covering triage and AI

[PATCH 0/3] Documentation: security-bugs: new updates covering triage and AI

[Willy Tarreau]

This series tries to translate recent discussions on the security list
on how to better handle reports. It details:
  - when not to Cc: the security list
  - what classes of bugs do not need to be handled privately
  - minimum requirements for AI-assisted reports

As usual, this is probably perfectible but can already help in the short
term as we can point it to reporters, so barring any strong disagreement,
better continue to proceed in small incremental improvements and observe
the effects.

Thanks!
Willy

---
Willy Tarreau (3):
  Documentation: security-bugs: do not systematically Cc the security
    team
  Documentation: security-bugs: explain what is and is not a security
    bug
  Documentation: security-bugs: clarify requirements for AI-assisted
    reports

 Documentation/process/security-bugs.rst | 131 ++++++++++++++++++++++--
 1 file changed, 120 insertions(+), 11 deletions(-)

-- 
2.52.0

[PATCH 1/3] Documentation: security-bugs: do not systematically Cc the security team

[Willy Tarreau]

With the increase of automated reports, the security team is dealing
with way more messages than really needed. The reporting process works
well with most teams so there is no need to systematically involve the
security team in reports.

Let's suggest to keep it for small lists of recipients, to cover the
risk of lost messages (spam, vacation etc) but to avoid it for larger
teams.

Cc: Greg KH <gregkh@linuxfoundation.org>
Cc: Leon Romanovsky <leon@kernel.org>
Signed-off-by: Willy Tarreau <w@1wt.eu>
---
 Documentation/process/security-bugs.rst | 26 ++++++++++++++-----------
 1 file changed, 15 insertions(+), 11 deletions(-)

diff --git a/Documentation/process/security-bugs.rst b/Documentation/process/security-bugs.rst
index 27b028e858610..a8a8fc724e8c8 100644
--- a/Documentation/process/security-bugs.rst
+++ b/Documentation/process/security-bugs.rst
@@ -70,11 +70,10 @@ 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).
+affected subsystem's maintainers.  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).
 
 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
@@ -148,12 +147,17 @@ 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.
 
-The report must be sent to maintainers, with the security team in ``Cc:``.
-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.
-It is possible that the security team will bring in extra help from area
-maintainers to understand and fix the security vulnerability.
+The report must be sent to maintainers.  If there are two or fewer recipients
+in your message, and only in this case, you can also Cc: the Linux kernel
+security team who will ensure the message is delivered to the proper people,
+and will be able to assist small maintainers teams with a process they are not
+necessarily familiar with.  For larger teams, please do not Cc: the Linux
+kernel security team, unless you're seeking specific help (e.g. when resending
+a message which got no response within a week).  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.  It is possible that the security team will bring in extra
+help from area maintainers to understand and fix the security vulnerability.
 
 Please send **plain text** emails without attachments where possible.
 It is much harder to have a context-quoted discussion about a complex
-- 
2.52.0

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

[Willy Tarreau]

The use of automated tools to find bugs in random locations of the kernel
induces a raise of security reports even if most of them should just be
reported as regular bugs. This patch is an attempt at drawing a line
between what qualifies as a security bug and what does not, hoping to
improve the situation.

Cc: Greg KH <gregkh@linuxfoundation.org>
Cc: Leon Romanovsky <leon@kernel.org>
Suggested-by: Leon Romanovsky <leon@kernel.org>
Signed-off-by: Willy Tarreau <w@1wt.eu>
---

Leon, while we started this list before our discussion, I reused most of
your proposal which was more comprehensive, and merged our initial work
into it. I added you in Suggested-by: but I think that Co-developed-by:
would be more suitable. If so, for this you'll have to also sign-off the
patch. It's as you prefer, I personally don't care.

---
 Documentation/process/security-bugs.rst | 50 +++++++++++++++++++++++++
 1 file changed, 50 insertions(+)

diff --git a/Documentation/process/security-bugs.rst b/Documentation/process/security-bugs.rst
index a8a8fc724e8c8..7cc3a1970ca00 100644
--- a/Documentation/process/security-bugs.rst
+++ b/Documentation/process/security-bugs.rst
@@ -66,6 +66,56 @@ 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 to the security team are
+just regular bugs that have been improperly qualified as security bugs due to a
+misunderstanding of the Linux kernel's threat model, and ought to have been
+sent through the normal channels described in
+'Documentation/admin-guide/reporting-issues.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
+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.
+
+In the Linux kernel's threat model, an issue is **not** a security bug, and
+should not be reported to the security list, when triggering it requires the
+reporter to first undermine the system they are attacking.  This includes, but
+is not limited to, behavior that only manifests after the administrator has
+explicitly enabled it (loading a module, setting a sysctl, writing to a debugfs
+knob, or otherwise using an interface documented as privileged or unsafe); bugs
+reachable only through root or CAP_SYS_ADMIN or CAP_NET_ADMIN on a machine the
+actor already fully controls, with no further privilege boundary being crossed;
+prediction of random numbers that only works in a totally silent environment
+(such as IP ID, TCP ports or sequence numbers that can only be guessed in a
+lab), issues that appear only in debug, lockdep, KASAN, fault-injection,
+CONFIG_NOMMU, or other developer-oriented kernel builds that are not intended
+for production use; problems seen only under development simulators, emulators,
+or fuzzing harnesses that present hardware or input states which cannot occur
+on real systems; bugs that require modified or emulated hardware; missing
+hardening or defence-in-depth suggestions with no demonstrable exploit path
+(including local ASLR bypass); mounting file systems that would be fixed or
+rejected by fsck; and bugs in out-of-tree modules or vendor forks, which should
+be reported to the relevant vendor.  Functional and performance regressions,
+and disagreements with documented kernel policy (for example, "root can load
+modules"), are likewise ordinary bugs or feature requests rather than security
+issues, and should be reported via the usual channels.
+
+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
 --------------------
 
-- 
2.52.0

[PATCH 3/3] Documentation: security-bugs: clarify requirements for AI-assisted reports

[Willy Tarreau]

AI tools are increasingly used to assist in bug discovery. While these
tools can identify valid issues, reports that are submitted without
manual verification often lack context, contain speculative impact
assessments, or include unnecessary formatting. Such reports increase
triage effort, waste maintainers' time and may be ignored.

Reports where the reporter has verified the issue and the proposed fix
typically meet quality standards. This documentation outlines specific
requirements for length, formatting, and impact evaluation to reduce
the effort needed to deal with these reports.

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

diff --git a/Documentation/process/security-bugs.rst b/Documentation/process/security-bugs.rst
index 7cc3a1970ca00..803d8819694e7 100644
--- a/Documentation/process/security-bugs.rst
+++ b/Documentation/process/security-bugs.rst
@@ -180,6 +180,61 @@ 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
+----------------------------------
+
+A significant fraction of bug reports submitted to the security team are
+actually the result of code reviews assisted by AI tools. While this can be an
+efficient means to find bugs in rarely explored areas, it causes an overload on
+maintainers, who are sometimes forced to ignore such reports due to their poor
+quality or accuracy. As such, reporters must be particularly cautious about a
+number of points which tend to make these reports needlessly difficult to
+handle:
+
+  * **Length**: AI-generated reports tend to be excessively long, containing
+    multiple sections and excessive detail. This makes it difficult to spot
+    important information such as affected files, versions, and impact. Please
+    ensure that a clear summary of the problem and all critical details are
+    presented first. Do not require triage engineers to scan multiple pages of
+    text. Configure your tools to produce concise, human-style reports.
+
+  * **Formatting**: Most AI-generated reports are littered with Markdown tags.
+    These decorations complicate the search for important information and do
+    not survive the quoting processes involved in forwarding or replying.
+    Please **always convert your report to plain text** without any formatting
+    decorations before sending it.
+
+  * **Impact Evaluation**: Many AI-generated reports lack an understanding of
+    the kernel's threat model and go to great lengths inventing theoretical
+    consequences. This adds noise and complicates triage. Please stick to
+    verifiable facts (e.g., "this bug permits any user to gain CAP_NET_ADMIN")
+    without enumerating speculative implications. Have your tool read this
+    documentation as part of the evaluation process.
+
+  * **Reproducer**: AI-based tools are often capable of generating reproducers.
+    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.
+
+  * **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
+    reporting the problem. If the fix cannot be tested because it relies on
+    rare hardware or almost extinct network protocols, the issue is likely not
+    a security bug. In any case, if a fix is proposed, it must adhere to
+    Documentation/process/submitting-patches.rst and include a 'Fixes:' tag
+    designating the commit that introduced the bug.
+
+Failure to consider these points exposes your report to the risk of being
+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, obsolte 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.
+
 Sending the report
 ------------------
 
-- 
2.52.0

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

[Randy Dunlap]

On 4/26/26 9:39 AM, Willy Tarreau wrote:
> The use of automated tools to find bugs in random locations of the kernel
> induces a raise of security reports even if most of them should just be
> reported as regular bugs. This patch is an attempt at drawing a line
> between what qualifies as a security bug and what does not, hoping to
> improve the situation.
> 
> Cc: Greg KH <gregkh@linuxfoundation.org>
> Cc: Leon Romanovsky <leon@kernel.org>
> Suggested-by: Leon Romanovsky <leon@kernel.org>
> Signed-off-by: Willy Tarreau <w@1wt.eu>
> ---
> 
> Leon, while we started this list before our discussion, I reused most of
> your proposal which was more comprehensive, and merged our initial work
> into it. I added you in Suggested-by: but I think that Co-developed-by:
> would be more suitable. If so, for this you'll have to also sign-off the
> patch. It's as you prefer, I personally don't care.
> 
> ---
>  Documentation/process/security-bugs.rst | 50 +++++++++++++++++++++++++
>  1 file changed, 50 insertions(+)
> 
> diff --git a/Documentation/process/security-bugs.rst b/Documentation/process/security-bugs.rst
> index a8a8fc724e8c8..7cc3a1970ca00 100644
> --- a/Documentation/process/security-bugs.rst
> +++ b/Documentation/process/security-bugs.rst
> @@ -66,6 +66,56 @@ 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 to the security team are
> +just regular bugs that have been improperly qualified as security bugs due to a
> +misunderstanding of the Linux kernel's threat model, and ought to have been
> +sent through the normal channels described in
> +'Documentation/admin-guide/reporting-issues.rst'.

Remove the <'> marks and let automarkup handle the filename.

-- 
~Randy

Re: [PATCH 3/3] Documentation: security-bugs: clarify requirements for AI-assisted reports

[Randy Dunlap]

On 4/26/26 9:39 AM, Willy Tarreau wrote:
> +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, obsolte filesystems). In such cases,

                                         obsolete

> +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.

-- 
~Randy

Re: [PATCH 3/3] Documentation: security-bugs: clarify requirements for AI-assisted reports

[Willy Tarreau]

On Sun, Apr 26, 2026 at 12:36:28PM -0700, Randy Dunlap wrote:
> 
> 
> On 4/26/26 9:39 AM, Willy Tarreau wrote:
> > +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, obsolte filesystems). In such cases,
> 
>                                          obsolete
(...)

Thank you Randy for your reviews! I'll apply the fixes and resend in a
few days if there are no more comments.

Willy

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

[Greg KH]

On Sun, Apr 26, 2026 at 06:39:13PM +0200, Willy Tarreau wrote:
> +In the Linux kernel's threat model, an issue is **not** a security bug, and
> +should not be reported to the security list, when triggering it requires the
> +reporter to first undermine the system they are attacking.  This includes, but
> +is not limited to, behavior that only manifests after the administrator has
> +explicitly enabled it (loading a module, setting a sysctl, writing to a debugfs
> +knob, or otherwise using an interface documented as privileged or unsafe); bugs
> +reachable only through root or CAP_SYS_ADMIN or CAP_NET_ADMIN on a machine the
> +actor already fully controls, with no further privilege boundary being crossed;
> +prediction of random numbers that only works in a totally silent environment
> +(such as IP ID, TCP ports or sequence numbers that can only be guessed in a
> +lab), issues that appear only in debug, lockdep, KASAN, fault-injection,
> +CONFIG_NOMMU, or other developer-oriented kernel builds that are not intended
> +for production use; problems seen only under development simulators, emulators,
> +or fuzzing harnesses that present hardware or input states which cannot occur
> +on real systems; bugs that require modified or emulated hardware; missing
> +hardening or defence-in-depth suggestions with no demonstrable exploit path
> +(including local ASLR bypass); mounting file systems that would be fixed or
> +rejected by fsck; and bugs in out-of-tree modules or vendor forks, which should
> +be reported to the relevant vendor.  Functional and performance regressions,
> +and disagreements with documented kernel policy (for example, "root can load
> +modules"), are likewise ordinary bugs or feature requests rather than security
> +issues, and should be reported via the usual channels.

This is a great list to start with, but perhaps we should put it in list
form so that it's easier to read?

Also, I can see this turning into a separate document eventually as
different subsystems should have a chance to weigh in on what they
consider the threat model to be (like what the IB subsystem does which I
don't think you listed above, or the USB subsystem.)

thanks,

greg k-h

Re: [PATCH 1/3] Documentation: security-bugs: do not systematically Cc the security team

[Greg KH]

On Sun, Apr 26, 2026 at 06:39:12PM +0200, Willy Tarreau wrote:
> With the increase of automated reports, the security team is dealing
> with way more messages than really needed. The reporting process works
> well with most teams so there is no need to systematically involve the
> security team in reports.
> 
> Let's suggest to keep it for small lists of recipients, to cover the
> risk of lost messages (spam, vacation etc) but to avoid it for larger
> teams.
> 
> Cc: Greg KH <gregkh@linuxfoundation.org>
> Cc: Leon Romanovsky <leon@kernel.org>
> Signed-off-by: Willy Tarreau <w@1wt.eu>

This is going to cut down on emails to us a bunch, which might be good,
or not, as now we'll not have a way to know what's going on overall.
But hey, let's try it and see what happens!

Acked-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

Re: [PATCH 3/3] Documentation: security-bugs: clarify requirements for AI-assisted reports

[Greg KH]

On Sun, Apr 26, 2026 at 06:39:14PM +0200, Willy Tarreau wrote:
> AI tools are increasingly used to assist in bug discovery. While these
> tools can identify valid issues, reports that are submitted without
> manual verification often lack context, contain speculative impact
> assessments, or include unnecessary formatting. Such reports increase
> triage effort, waste maintainers' time and may be ignored.
> 
> Reports where the reporter has verified the issue and the proposed fix
> typically meet quality standards. This documentation outlines specific
> requirements for length, formatting, and impact evaluation to reduce
> the effort needed to deal with these reports.
> 
> Cc: Greg KH <gregkh@linuxfoundation.org>
> Signed-off-by: Willy Tarreau <w@1wt.eu>
> ---
>  Documentation/process/security-bugs.rst | 55 +++++++++++++++++++++++++
>  1 file changed, 55 insertions(+)

Nice addition!

Acked-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

Re: [PATCH 1/3] Documentation: security-bugs: do not systematically Cc the security team

[Willy Tarreau]

On Mon, Apr 27, 2026 at 07:49:08AM -0600, Greg KH wrote:
> On Sun, Apr 26, 2026 at 06:39:12PM +0200, Willy Tarreau wrote:
> > With the increase of automated reports, the security team is dealing
> > with way more messages than really needed. The reporting process works
> > well with most teams so there is no need to systematically involve the
> > security team in reports.
> > 
> > Let's suggest to keep it for small lists of recipients, to cover the
> > risk of lost messages (spam, vacation etc) but to avoid it for larger
> > teams.
> > 
> > Cc: Greg KH <gregkh@linuxfoundation.org>
> > Cc: Leon Romanovsky <leon@kernel.org>
> > Signed-off-by: Willy Tarreau <w@1wt.eu>
> 
> This is going to cut down on emails to us a bunch, which might be good,
> or not, as now we'll not have a way to know what's going on overall.
> But hey, let's try it and see what happens!

Or maybe we could suggest that first reports from a reporter should
always Cc the list ? After all, every time we asked to drop the list
was for senders at their 5th or 10th submission. Maybe we could just
say that the list members prefer not being repetitively CCed by the
same submitters to invest more time on newcomers ?

> Acked-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

Thanks!
willy

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

[Willy Tarreau]

On Mon, Apr 27, 2026 at 07:48:23AM -0600, Greg KH wrote:
> On Sun, Apr 26, 2026 at 06:39:13PM +0200, Willy Tarreau wrote:
> > +In the Linux kernel's threat model, an issue is **not** a security bug, and
> > +should not be reported to the security list, when triggering it requires the
> > +reporter to first undermine the system they are attacking.  This includes, but
> > +is not limited to, behavior that only manifests after the administrator has
> > +explicitly enabled it (loading a module, setting a sysctl, writing to a debugfs
> > +knob, or otherwise using an interface documented as privileged or unsafe); bugs
> > +reachable only through root or CAP_SYS_ADMIN or CAP_NET_ADMIN on a machine the
> > +actor already fully controls, with no further privilege boundary being crossed;
> > +prediction of random numbers that only works in a totally silent environment
> > +(such as IP ID, TCP ports or sequence numbers that can only be guessed in a
> > +lab), issues that appear only in debug, lockdep, KASAN, fault-injection,
> > +CONFIG_NOMMU, or other developer-oriented kernel builds that are not intended
> > +for production use; problems seen only under development simulators, emulators,
> > +or fuzzing harnesses that present hardware or input states which cannot occur
> > +on real systems; bugs that require modified or emulated hardware; missing
> > +hardening or defence-in-depth suggestions with no demonstrable exploit path
> > +(including local ASLR bypass); mounting file systems that would be fixed or
> > +rejected by fsck; and bugs in out-of-tree modules or vendor forks, which should
> > +be reported to the relevant vendor.  Functional and performance regressions,
> > +and disagreements with documented kernel policy (for example, "root can load
> > +modules"), are likewise ordinary bugs or feature requests rather than security
> > +issues, and should be reported via the usual channels.
> 
> This is a great list to start with, but perhaps we should put it in list
> form so that it's easier to read?

In fact that's what I tried first and it was super long with many short
lines, making it possibly worse. But maybe aggregating several short
entries on a line by similarities could work, I can give it a try.

> Also, I can see this turning into a separate document eventually as
> different subsystems should have a chance to weigh in on what they
> consider the threat model to be

My fear if we redirect to other files is that it won't be read again.
However, we could possibly suggest to always look for the subsystem's
specific rules in this subsytem's doc, leaving enough freedom to
maintainers to reject more things.

> (like what the IB subsystem does which I
> don't think you listed above, or the USB subsystem.)

Indeed I didn't list IB (I'm never sure about it, I seem to remember
we simply trust any peer, is that right?), nor did I make specific
mentions for USB which is implicitly covered by "hardware emulation
or modification".

thanks!
Willy

Re: [PATCH 1/3] Documentation: security-bugs: do not systematically Cc the security team

[Greg KH]

On Mon, Apr 27, 2026 at 05:24:06PM +0200, Willy Tarreau wrote:
> On Mon, Apr 27, 2026 at 07:49:08AM -0600, Greg KH wrote:
> > On Sun, Apr 26, 2026 at 06:39:12PM +0200, Willy Tarreau wrote:
> > > With the increase of automated reports, the security team is dealing
> > > with way more messages than really needed. The reporting process works
> > > well with most teams so there is no need to systematically involve the
> > > security team in reports.
> > > 
> > > Let's suggest to keep it for small lists of recipients, to cover the
> > > risk of lost messages (spam, vacation etc) but to avoid it for larger
> > > teams.
> > > 
> > > Cc: Greg KH <gregkh@linuxfoundation.org>
> > > Cc: Leon Romanovsky <leon@kernel.org>
> > > Signed-off-by: Willy Tarreau <w@1wt.eu>
> > 
> > This is going to cut down on emails to us a bunch, which might be good,
> > or not, as now we'll not have a way to know what's going on overall.
> > But hey, let's try it and see what happens!
> 
> Or maybe we could suggest that first reports from a reporter should
> always Cc the list ? After all, every time we asked to drop the list
> was for senders at their 5th or 10th submission. Maybe we could just
> say that the list members prefer not being repetitively CCed by the
> same submitters to invest more time on newcomers ?

Yes, that might be better, otherwise maintainers are going to get some
pretty foolish reports with out the context of howing to properly at
least push back on them, like we have gotten good at doing :)

thanks,
greg k-h

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

[Greg KH]

On Mon, Apr 27, 2026 at 05:27:46PM +0200, Willy Tarreau wrote:
> On Mon, Apr 27, 2026 at 07:48:23AM -0600, Greg KH wrote:
> > On Sun, Apr 26, 2026 at 06:39:13PM +0200, Willy Tarreau wrote:
> > > +In the Linux kernel's threat model, an issue is **not** a security bug, and
> > > +should not be reported to the security list, when triggering it requires the
> > > +reporter to first undermine the system they are attacking.  This includes, but
> > > +is not limited to, behavior that only manifests after the administrator has
> > > +explicitly enabled it (loading a module, setting a sysctl, writing to a debugfs
> > > +knob, or otherwise using an interface documented as privileged or unsafe); bugs
> > > +reachable only through root or CAP_SYS_ADMIN or CAP_NET_ADMIN on a machine the
> > > +actor already fully controls, with no further privilege boundary being crossed;
> > > +prediction of random numbers that only works in a totally silent environment
> > > +(such as IP ID, TCP ports or sequence numbers that can only be guessed in a
> > > +lab), issues that appear only in debug, lockdep, KASAN, fault-injection,
> > > +CONFIG_NOMMU, or other developer-oriented kernel builds that are not intended
> > > +for production use; problems seen only under development simulators, emulators,
> > > +or fuzzing harnesses that present hardware or input states which cannot occur
> > > +on real systems; bugs that require modified or emulated hardware; missing
> > > +hardening or defence-in-depth suggestions with no demonstrable exploit path
> > > +(including local ASLR bypass); mounting file systems that would be fixed or
> > > +rejected by fsck; and bugs in out-of-tree modules or vendor forks, which should
> > > +be reported to the relevant vendor.  Functional and performance regressions,
> > > +and disagreements with documented kernel policy (for example, "root can load
> > > +modules"), are likewise ordinary bugs or feature requests rather than security
> > > +issues, and should be reported via the usual channels.
> > 
> > This is a great list to start with, but perhaps we should put it in list
> > form so that it's easier to read?
> 
> In fact that's what I tried first and it was super long with many short
> lines, making it possibly worse. But maybe aggregating several short
> entries on a line by similarities could work, I can give it a try.
> 
> > Also, I can see this turning into a separate document eventually as
> > different subsystems should have a chance to weigh in on what they
> > consider the threat model to be
> 
> My fear if we redirect to other files is that it won't be read again.
> However, we could possibly suggest to always look for the subsystem's
> specific rules in this subsytem's doc, leaving enough freedom to
> maintainers to reject more things.

AI tools are good at following links, so I wouldn't worry about that.
We can point at other files, as this list is going to get long over
time, which is a good thing.

> > (like what the IB subsystem does which I
> > don't think you listed above, or the USB subsystem.)
> 
> Indeed I didn't list IB (I'm never sure about it, I seem to remember
> we simply trust any peer, is that right?), nor did I make specific
> mentions for USB which is implicitly covered by "hardware emulation
> or modification".

Ah, but USB does cover "some" modification of devices, so this is going
to be something that is good to document over time, if for no other
reason to keep these scanning tools in check from hallucinating crazy
situations that are obviously not a valid thing we care about.

thanks,

greg k-h