mirror of
https://mirrors.bfsu.edu.cn/git/linux.git
synced 2024-11-11 04:18:39 +08:00
5928d41155
The Linux kernel project now has the ability to assign CVEs to fixed issues, so document the process and how individual developers can get a CVE if one is not automatically assigned for their fixes. Reviewed-by: Kees Cook <keescook@chromium.org> Reviewed-by: Konstantin Ryabitsev <konstantin@linuxfoundation.org> Reviewed-by: Krzysztof Kozlowski <krzk@kernel.org> Reviewed-by: Lukas Bulwahn <lukas.bulwahn@gmail.com> Signed-off-by: Sasha Levin <sashal@kernel.org> Signed-off-by: Lee Jones <lee@kernel.org> Link: https://lore.kernel.org/r/2024021731-essence-sadness-28fd@gregkh Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
110 lines
5.0 KiB
ReStructuredText
110 lines
5.0 KiB
ReStructuredText
.. _securitybugs:
|
|
|
|
Security bugs
|
|
=============
|
|
|
|
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. Please report security bugs to the
|
|
Linux kernel security team.
|
|
|
|
Contact
|
|
-------
|
|
|
|
The Linux kernel security team can be contacted by email at
|
|
<security@kernel.org>. This is a private list of security officers
|
|
who will help verify the bug report and develop and release a fix.
|
|
If you already have a fix, please include it with your report, as
|
|
that can speed up the process considerably. It is possible that the
|
|
security team will bring in extra help from area maintainers to
|
|
understand and fix the security vulnerability.
|
|
|
|
As it is with any bug, the more information provided the easier it
|
|
will be to diagnose and fix. Please review the procedure outlined in
|
|
'Documentation/admin-guide/reporting-issues.rst' if you are unclear about what
|
|
information is helpful. Any exploit code is very helpful and will not
|
|
be released without consent from the reporter unless it has already been
|
|
made public.
|
|
|
|
Please send plain text emails without attachments where possible.
|
|
It is much harder to have a context-quoted discussion about a complex
|
|
issue if all the details are hidden away in attachments. Think of it like a
|
|
:doc:`regular patch submission <../process/submitting-patches>`
|
|
(even if you don't have a patch yet): describe the problem and impact, list
|
|
reproduction steps, and follow it with a proposed fix, all in plain text.
|
|
|
|
Disclosure and embargoed information
|
|
------------------------------------
|
|
|
|
The security list is not a disclosure channel. For that, see Coordination
|
|
below.
|
|
|
|
Once a robust fix has been developed, the release process starts. Fixes
|
|
for publicly known bugs are released immediately.
|
|
|
|
Although our preference is to release fixes for publicly undisclosed bugs
|
|
as soon as they become available, this may be postponed at the request of
|
|
the reporter or an affected party for up to 7 calendar days from the start
|
|
of the release process, with an exceptional extension to 14 calendar days
|
|
if it is agreed that the criticality of the bug requires more time. The
|
|
only valid reason for deferring the publication of a fix is to accommodate
|
|
the logistics of QA and large scale rollouts which require release
|
|
coordination.
|
|
|
|
While embargoed information may be shared with trusted individuals in
|
|
order to develop a fix, such information will not be published alongside
|
|
the fix or on any other disclosure channel without the permission of the
|
|
reporter. This includes but is not limited to the original bug report
|
|
and followup discussions (if any), exploits, CVE information or the
|
|
identity of the reporter.
|
|
|
|
In other words our only interest is in getting bugs fixed. All other
|
|
information submitted to the security list and any followup discussions
|
|
of the report are treated confidentially even after the embargo has been
|
|
lifted, in perpetuity.
|
|
|
|
Coordination with other groups
|
|
------------------------------
|
|
|
|
While the kernel security team solely focuses on getting bugs fixed,
|
|
other groups focus on fixing issues in distros and coordinating
|
|
disclosure between operating system vendors. Coordination is usually
|
|
handled by the "linux-distros" mailing list and disclosure by the
|
|
public "oss-security" mailing list, both of which are closely related
|
|
and presented in the linux-distros wiki:
|
|
<https://oss-security.openwall.org/wiki/mailing-lists/distros>
|
|
|
|
Please note that the respective policies and rules are different since
|
|
the 3 lists pursue different goals. Coordinating between the kernel
|
|
security team and other teams is difficult since for the kernel security
|
|
team occasional embargoes (as subject to a maximum allowed number of
|
|
days) start from the availability of a fix, while for "linux-distros"
|
|
they start from the initial post to the list regardless of the
|
|
availability of a fix.
|
|
|
|
As such, the kernel security team strongly recommends that as a reporter
|
|
of a potential security issue you DO NOT contact the "linux-distros"
|
|
mailing list UNTIL a fix is accepted by the affected code's maintainers
|
|
and you have read the distros wiki page above and you fully understand
|
|
the requirements that contacting "linux-distros" will impose on you and
|
|
the kernel community. This also means that in general it doesn't make
|
|
sense to Cc: both lists at once, except maybe for coordination if and
|
|
while an accepted fix has not yet been merged. In other words, until a
|
|
fix is accepted do not Cc: "linux-distros", and after it's merged do not
|
|
Cc: the kernel security team.
|
|
|
|
CVE assignment
|
|
--------------
|
|
|
|
The security team does not assign CVEs, nor do we require them for
|
|
reports or fixes, as this can needlessly complicate the process and may
|
|
delay the bug handling. If a reporter wishes to have a CVE identifier
|
|
assigned for a confirmed issue, they can contact the :doc:`kernel CVE
|
|
assignment team<../process/cve>` to obtain one.
|
|
|
|
Non-disclosure agreements
|
|
-------------------------
|
|
|
|
The Linux kernel security team is not a formal body and therefore unable
|
|
to enter any non-disclosure agreements.
|