Linux kernel mirror (for testing)
git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
kernel
os
linux
Documentation: clarify the mandatory and desirable info for security reports
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>
Link: https://patch.msgid.link/20260403062018.31080-4-w@1wt.eu
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
authored by
Willy Tarreau
and committed by
Greg Kroah-Hartman
496fa1be
a72b832a
+59
-7
+59
-7
Documentation/process/security-bugs.rst
+59
-7
Documentation/process/security-bugs.rst
···
7
7
like to know when a security bug is found so that it can be fixed and
8
8
disclosed as quickly as possible.
9
9
10
+
Preparing your report
11
+
---------------------
12
+
13
+
Like with any bug report, a security bug report requires a lot of analysis work
14
+
from the developers, so the more information you can share about the issue, the
15
+
better. Please review the procedure outlined in
16
+
Documentation/admin-guide/reporting-issues.rst if you are unclear about what
17
+
information is helpful. The following information are absolutely necessary in
18
+
**any** security bug report:
19
+
20
+
* **affected kernel version range**: with no version indication, your report
21
+
will not be processed. A significant part of reports are for bugs that
22
+
have already been fixed, so it is extremely important that vulnerabilities
23
+
are verified on recent versions (development tree or latest stable
24
+
version), at least by verifying that the code has not changed since the
25
+
version where it was detected.
26
+
27
+
* **description of the problem**: a detailed description of the problem, with
28
+
traces showing its manifestation, and why you consider that the observed
29
+
behavior as a problem in the kernel, is necessary.
30
+
31
+
* **reproducer**: developers will need to be able to reproduce the problem to
32
+
consider a fix as effective. This includes both a way to trigger the issue
33
+
and a way to confirm it happens. A reproducer with low complexity
34
+
dependencies will be needed (source code, shell script, sequence of
35
+
instructions, file-system image etc). Binary-only executables are not
36
+
accepted. Working exploits are extremely helpful and will not be released
37
+
without consent from the reporter, unless they are already public. By
38
+
definition if an issue cannot be reproduced, it is not exploitable, thus it
39
+
is not a security bug.
40
+
41
+
* **conditions**: if the bug depends on certain configuration options,
42
+
sysctls, permissions, timing, code modifications etc, these should be
43
+
indicated.
44
+
45
+
In addition, the following information are highly desirable:
46
+
47
+
* **suspected location of the bug**: the file names and functions where the
48
+
bug is suspected to be present are very important, at least to help forward
49
+
the report to the appropriate maintainers. When not possible (for example,
50
+
"system freezes each time I run this command"), the security team will help
51
+
identify the source of the bug.
52
+
53
+
* **a proposed fix**: bug reporters who have analyzed the cause of a bug in
54
+
the source code almost always have an accurate idea on how to fix it,
55
+
because they spent a long time studying it and its implications. Proposing
56
+
a tested fix will save maintainers a lot of time, even if the fix ends up
57
+
not being the right one, because it helps understand the bug. When
58
+
proposing a tested fix, please always format it in a way that can be
59
+
immediately merged (see Documentation/process/submitting-patches.rst).
60
+
This will save some back-and-forth exchanges if it is accepted, and you
61
+
will be credited for finding and fixing this issue. Note that in this case
62
+
only a ``Signed-off-by:`` tag is needed, without ``Reported-by:` when the
63
+
reporter and author are the same.
64
+
65
+
* **mitigations**: very often during a bug analysis, some ways of mitigating
66
+
the issue appear. It is useful to share them, as they can be helpful to
67
+
keep end users protected during the time it takes them to apply the fix.
68
+
10
69
Identifying contacts
11
70
--------------------
12
71
···
147
88
run additional tests. Reports where the reporter does not respond promptly
148
89
or cannot effectively discuss their findings may be abandoned if the
149
90
communication does not quickly improve.
150
-
151
-
As it is with any bug, the more information provided the easier it
152
-
will be to diagnose and fix. Please review the procedure outlined in
153
-
'Documentation/admin-guide/reporting-issues.rst' if you are unclear about what
154
-
information is helpful. Any exploit code is very helpful and will not
155
-
be released without consent from the reporter unless it has already been
156
-
made public.
157
91
158
92
The report must be sent to maintainers, with the security team in ``Cc:``.
159
93
The Linux kernel security team can be contacted by email at