Linux kernel mirror (for testing)
git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
kernel
os
linux
Documentation: explain how to find maintainers addresses for security reports
These days, 80% of the work done by the security team consists in
locating the affected subsystem in a report, running get_maintainers on
it, forwarding the report to these persons and responding to the reporter
with them in Cc. This is a huge and unneeded overhead that we must try to
lower for a better overall efficiency. This patch adds a complete section
explaining how to figure the list of recipients to send the report to.
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-3-w@1wt.eu
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
authored by
Willy Tarreau
and committed by
Greg Kroah-Hartman
a72b832a
f2b1cbef
+73
-3
+73
-3
Documentation/process/security-bugs.rst
+73
-3
Documentation/process/security-bugs.rst
···
5
5
6
6
Linux kernel developers take security very seriously. As such, we'd
7
7
like to know when a security bug is found so that it can be fixed and
8
-
disclosed as quickly as possible. Please report security bugs to the
9
-
Linux kernel security team.
8
+
disclosed as quickly as possible.
9
+
10
+
Identifying contacts
11
+
--------------------
12
+
13
+
The most effective way to report a security bug is to send it directly to the
14
+
affected subsystem's maintainers and Cc: the Linux kernel security team. Do
15
+
not send it to a public list at this stage, unless you have good reasons to
16
+
consider the issue as being public or trivial to discover (e.g. result of a
17
+
widely available automated vulnerability scanning tool that can be repeated by
18
+
anyone).
19
+
20
+
If you're sending a report for issues affecting multiple parts in the kernel,
21
+
even if they're fairly similar issues, please send individual messages (think
22
+
that maintainers will not all work on the issues at the same time). The only
23
+
exception is when an issue concerns closely related parts maintained by the
24
+
exact same subset of maintainers, and these parts are expected to be fixed all
25
+
at once by the same commit, then it may be acceptable to report them at once.
26
+
27
+
One difficulty for most first-time reporters is to figure the right list of
28
+
recipients to send a report to. In the Linux kernel, all official maintainers
29
+
are trusted, so the consequences of accidentally including the wrong maintainer
30
+
are essentially a bit more noise for that person, i.e. nothing dramatic. As
31
+
such, a suitable method to figure the list of maintainers (which kernel
32
+
security officers use) is to rely on the get_maintainers.pl script, tuned to
33
+
only report maintainers. This script, when passed a file name, will look for
34
+
its path in the MAINTAINERS file to figure a hierarchical list of relevant
35
+
maintainers. Calling it a first time with the finest level of filtering will
36
+
most of the time return a short list of this specific file's maintainers::
37
+
38
+
$ ./scripts/get_maintainer.pl --no-l --no-r --pattern-depth 1 \
39
+
drivers/example.c
40
+
Developer One <dev1@example.com> (maintainer:example driver)
41
+
Developer Two <dev2@example.org> (maintainer:example driver)
42
+
43
+
These two maintainers should then receive the message. If the command does not
44
+
return anything, it means the affected file is part of a wider subsystem, so we
45
+
should be less specific::
46
+
47
+
$ ./scripts/get_maintainer.pl --no-l --no-r drivers/example.c
48
+
Developer One <dev1@example.com> (maintainer:example subsystem)
49
+
Developer Two <dev2@example.org> (maintainer:example subsystem)
50
+
Developer Three <dev3@example.com> (maintainer:example subsystem [GENERAL])
51
+
Developer Four <dev4@example.org> (maintainer:example subsystem [GENERAL])
52
+
53
+
Here, picking the first, most specific ones, is sufficient. When the list is
54
+
long, it is possible to produce a comma-delimited e-mail address list on a
55
+
single line suitable for use in the To: field of a mailer like this::
56
+
57
+
$ ./scripts/get_maintainer.pl --no-tree --no-l --no-r --no-n --m \
58
+
--no-git-fallback --no-substatus --no-rolestats --no-multiline \
59
+
--pattern-depth 1 drivers/example.c
60
+
dev1@example.com, dev2@example.org
61
+
62
+
or this for the wider list::
63
+
64
+
$ ./scripts/get_maintainer.pl --no-tree --no-l --no-r --no-n --m \
65
+
--no-git-fallback --no-substatus --no-rolestats --no-multiline \
66
+
drivers/example.c
67
+
dev1@example.com, dev2@example.org, dev3@example.com, dev4@example.org
68
+
69
+
If at this point you're still facing difficulties spotting the right
70
+
maintainers, **and only in this case**, it's possible to send your report to
71
+
the Linux kernel security team only. Your message will be triaged, and you
72
+
will receive instructions about whom to contact, if needed. Your message may
73
+
equally be forwarded as-is to the relevant maintainers.
74
+
75
+
Sending the report
76
+
------------------
10
77
11
78
Reports are to be sent over e-mail exclusively. Please use a working e-mail
12
79
address, preferably the same that you want to appear in ``Reported-by`` tags
···
96
29
be released without consent from the reporter unless it has already been
97
30
made public.
98
31
32
+
The report must be sent to maintainers, with the security team in ``Cc:``.
99
33
The Linux kernel security team can be contacted by email at
100
34
<security@kernel.org>. This is a private list of security officers
101
35
who will help verify the bug report and assist developers working on a fix.
···
112
44
Markdown, HTML and RST formatted reports are particularly frowned upon since
113
45
they're quite hard to read for humans and encourage to use dedicated viewers,
114
46
sometimes online, which by definition is not acceptable for a confidential
115
-
security report.
47
+
security report. Note that some mailers tend to mangle formatting of plain
48
+
text by default, please consult Documentation/process/email-clients.rst for
49
+
more info.
116
50
117
51
Disclosure and embargoed information
118
52
------------------------------------