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 <[email protected]> > > Cc: Greg KH <[email protected]> > > Signed-off-by: Willy Tarreau <[email protected]> > > --- > > 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. Thanks a lot for your help! Willy
