Re: [PATCH 3/3] Documentation: clarify the mandatory and desirable info for security reports

[Randy Dunlap]

On 4/2/26 11:26 AM, Willy Tarreau wrote:
> A significant part of the effort of the security team consists in begging
> reporters for patch proposals, or asking them to provide them in regular
> format, and most of the time they're willing to provide this, they just
> didn't know that it would help. So let's add a section detailing the
> required and desirable contents in a security report to help reporters
> write more actionable reports which do not require round trips.
> 
> Cc: Eric Dumazet <edumazet@xxxxxxxxxx>
> Cc: Greg KH <greg@xxxxxxxxx>
> Signed-off-by: Willy Tarreau <w@xxxxxx>
> ---
>  Documentation/process/security-bugs.rst | 66 ++++++++++++++++++++++---
>  1 file changed, 59 insertions(+), 7 deletions(-)
> 
> diff --git a/Documentation/process/security-bugs.rst b/Documentation/process/security-bugs.rst
> index 6937fa9fba5a..b243ac24eb12 100644
> --- a/Documentation/process/security-bugs.rst
> +++ b/Documentation/process/security-bugs.rst
> @@ -7,6 +7,65 @@ 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.
>  
> +Preparing your report
> +---------------------
> +
> +Like with any bug report, a security bug report requires a lot of analysis work
> +from the developers, so the more information you can share about the issue, the
> +better.  Please review the procedure outlined in
> +'Documentation/admin-guide/reporting-issues.rst' if you are unclear about what

Drop the single quote marks.

> +information is helpful.  The following information are absolutely necessary in
> +**any** security bug report:
> +
> +  * **affected kernel version range**: with no version indication, your report
> +    will not be processed.  A significant part of reports are for bugs that
> +    have already been fixed, so it is extremely important that vulnerabilities
> +    are verified on recent versions (development tree or latest stable
> +    version), at least by verifying that the code has not changed since the
> +    version where it was detected.
> +
> +  * **description of the problem**: a detailed description of the problem, with
> +    traces showing its manifestation, and why you consider that the observed
> +    behavior as a problem in the kernel, is necessary.
> +
> +  * **reproducer**: developers will need to be able to reproduce the problem to
> +    consider a fix as effective.  This includes both a way to trigger the issue
> +    and a way to confirm it happens.  A reproducer with low complexity
> +    dependencies will be needed (source code, shell script, sequence of
> +    instructions, file-system image etc).  Binary-only executables are not
> +    accepted.  Working exploits are extremely helpful and will not be released
> +    without consent from the reporter, unless they are already public.  By
> +    definition if an issue cannot be reproduced, it is not exploitable, thus it
> +    is not a security bug.
> +
> +  * **conditions**: if the bug depends on certain configuration options,
> +    sysctls, permissions, timing, code modifications etc, these should be
> +    indicated.
> +
> +In addition, the following information are highly desirable:
> +
> +  * **suspected location of the bug**: the file names and functions where the
> +    bug is suspected to be present are very important, at least to help forward
> +    the report to the appropriate maintainers.  When not possible (for example,
> +    "system freezes each time I run this command"), the security team will help
> +    identify the source of the bug.
> +
> +  * **a proposed fix**: bug reporters who have analyzed the cause of a bug in
> +    the source code almost always have an accurate idea on how to fix it,
> +    because they spent a long time studying it and its implications.  Proposing
> +    a tested fix will save maintainers a lot of time, even if the fix ends up
> +    not being the right one, because it helps understand the bug.  When
> +    proposing a tested fix, please always format it in a way that can be
> +    immediately merged (see :doc:`regular patch submission
> +    <../process/submitting-patches>`).  This will save some back-and-forth

Hm, I don't see anything in submitting-patches.rst called "regular patch submission".
Is it in some other patch?

> +    exchanges if it is accepted, and you will be credited for finding and
> +    fixing this issue.  Note that in this case only a ``Signed-off-by:`` tag is
> +    needed, without ``Reported-by:` when the reporter and author are the same.


-- 
~Randy