security-bugs.rst

  1.. _securitybugs:
  2
  3Security bugs
  4=============
  5
  6Linux kernel developers take security very seriously.  As such, we'd
  7like to know when a security bug is found so that it can be fixed and
  8disclosed as quickly as possible.  Please report security bugs to the
  9Linux kernel security team.
 10
 11The security team and maintainers almost always require additional
 12information beyond what was initially provided in a report and rely on
 13active and efficient collaboration with the reporter to perform further
 14testing (e.g., verifying versions, configuration options, mitigations, or
 15patches). Before contacting the security team, the reporter must ensure
 16they are available to explain their findings, engage in discussions, and
 17run additional tests.  Reports where the reporter does not respond promptly
 18or cannot effectively discuss their findings may be abandoned if the
 19communication does not quickly improve.
 20
 21As it is with any bug, the more information provided the easier it
 22will be to diagnose and fix.  Please review the procedure outlined in
 23'Documentation/admin-guide/reporting-issues.rst' if you are unclear about what
 24information is helpful.  Any exploit code is very helpful and will not
 25be released without consent from the reporter unless it has already been
 26made public.
 27
 28The Linux kernel security team can be contacted by email at
 29<security@kernel.org>.  This is a private list of security officers
 30who will help verify the bug report and develop and release a fix.
 31If you already have a fix, please include it with your report, as
 32that can speed up the process considerably.  It is possible that the
 33security team will bring in extra help from area maintainers to
 34understand and fix the security vulnerability.
 35
 36Please send plain text emails without attachments where possible.
 37It is much harder to have a context-quoted discussion about a complex
 38issue if all the details are hidden away in attachments.  Think of it like a
 39:doc:`regular patch submission <../process/submitting-patches>`
 40(even if you don't have a patch yet): describe the problem and impact, list
 41reproduction steps, and follow it with a proposed fix, all in plain text.
 42
 43Disclosure and embargoed information
 44------------------------------------
 45
 46The security list is not a disclosure channel.  For that, see Coordination
 47below.
 48
 49Once a robust fix has been developed, the release process starts.  Fixes
 50for publicly known bugs are released immediately.
 51
 52Although our preference is to release fixes for publicly undisclosed bugs
 53as soon as they become available, this may be postponed at the request of
 54the reporter or an affected party for up to 7 calendar days from the start
 55of the release process, with an exceptional extension to 14 calendar days
 56if it is agreed that the criticality of the bug requires more time.  The
 57only valid reason for deferring the publication of a fix is to accommodate
 58the logistics of QA and large scale rollouts which require release
 59coordination.
 60
 61While embargoed information may be shared with trusted individuals in
 62order to develop a fix, such information will not be published alongside
 63the fix or on any other disclosure channel without the permission of the
 64reporter.  This includes but is not limited to the original bug report
 65and followup discussions (if any), exploits, CVE information or the
 66identity of the reporter.
 67
 68In other words our only interest is in getting bugs fixed.  All other
 69information submitted to the security list and any followup discussions
 70of the report are treated confidentially even after the embargo has been
 71lifted, in perpetuity.
 72
 73Coordination with other groups
 74------------------------------
 75
 76While the kernel security team solely focuses on getting bugs fixed,
 77other groups focus on fixing issues in distros and coordinating
 78disclosure between operating system vendors.  Coordination is usually
 79handled by the "linux-distros" mailing list and disclosure by the
 80public "oss-security" mailing list, both of which are closely related
 81and presented in the linux-distros wiki:
 82<https://oss-security.openwall.org/wiki/mailing-lists/distros>
 83
 84Please note that the respective policies and rules are different since
 85the 3 lists pursue different goals.  Coordinating between the kernel
 86security team and other teams is difficult since for the kernel security
 87team occasional embargoes (as subject to a maximum allowed number of
 88days) start from the availability of a fix, while for "linux-distros"
 89they start from the initial post to the list regardless of the
 90availability of a fix.
 91
 92As such, the kernel security team strongly recommends that as a reporter
 93of a potential security issue you DO NOT contact the "linux-distros"
 94mailing list UNTIL a fix is accepted by the affected code's maintainers
 95and you have read the distros wiki page above and you fully understand
 96the requirements that contacting "linux-distros" will impose on you and
 97the kernel community.  This also means that in general it doesn't make
 98sense to Cc: both lists at once, except maybe for coordination if and
 99while an accepted fix has not yet been merged.  In other words, until a
100fix is accepted do not Cc: "linux-distros", and after it's merged do not
101Cc: the kernel security team.
102
103CVE assignment
104--------------
105
106The security team does not assign CVEs, nor do we require them for
107reports or fixes, as this can needlessly complicate the process and may
108delay the bug handling.  If a reporter wishes to have a CVE identifier
109assigned for a confirmed issue, they can contact the :doc:`kernel CVE
110assignment team<../process/cve>` to obtain one.
111
112Non-disclosure agreements
113-------------------------
114
115The Linux kernel security team is not a formal body and therefore unable
116to enter any non-disclosure agreements.