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

Randy Dunlap
2026-04-02T19:17:40Z

On 4/2/26 12:03 PM, Willy Tarreau wrote:
> Hi Randy,
>
> On Thu, Apr 02, 2026 at 11:50:00AM -0700, Randy Dunlap wrote:
>>
>> 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@google.com>
>>> Cc: Greg KH <greg@kroah.com>
>>> Signed-off-by: Willy Tarreau <w@1wt.eu>
>>> ---
>>> 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.
>
> I just moved this part as-is, and I've been extremely hesitant to change
> formatting as I can't easily check the validity of the output.
>
>>> +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?
>
> Not sure what you mean. Is this supposed to be a sub-section and not just a
> title ? On https://www.kernel.org/doc/html/latest/process/security-bugs.html
> it appears as the title. This one was already present in the same document
> and was moved there without a change.

I see. Sorry for the noise.

--
~Randy