Reporting 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 at security@kernel.org, henceforth “the security list”. This is a closed list of trusted developers who will help verify the bug report and develop a patch in case none was already proposed.
While the security list is closed, the security team may bring in extra help from the relevant maintainers to understand and fix the security vulnerability.
Note that the main interest of the kernel security list is in getting bugs fixed and getting patches reviewed, tested, and merged; CVE assignment, disclosure to distributions, and public disclosure happen on different lists with different people, as described below.
Here is a quick overview of the various lists:
List address
Open?
Purpose
Members
no
Trusted kernel developers
no
Distribution representatives
yes
General public
The following sections give a step-by-step guide to reporting and disclosure.
Contacting the security list¶
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 Reporting issues 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. Reporters are encouraged to propose patches, participate in the discussions of a fix, and test patches.
The security team does not assign CVEs, nor does it require them for reports or fixes. CVEs may be requested when the issue is reported to the linux-distros list.
Disclosure. The security list strongly prefers to have patches posted for review and testing on public mailing lists and and merged into the appropriate public git repository as soon as they become available. However, in exceptional cases, you or an affected party may request that the patch be withheld for some days; as a rule, the maximum is 7 days. Only in truly exceptional cases will the security list consider deferring the publication of a fix beyond this, and the only valid reason for doing so would be to accommodate the logistics of QA and large scale rollouts that require release coordination.
Please note that although a fix is public, there may still be value in withholding the details of its security relevance and/or how to exploit it for another while; see below for when and how to properly disclose the security impact of your findings publicly.
List rules. 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 regular patch submission (see Submitting patches: the essential guide to getting your code into the kernel) 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.
Confidentiality. 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. All such other information submitted to the security list and any follow-up discussions of the report are treated confidentially even after the embargo has been lifted, in perpetuity.
The Linux kernel security team is not a formal body and therefore unable to enter any non-disclosure agreements.
Once a patch has been developed, you are encouraged to contact the linux-distros list.
Contacting the linux-distros list¶
Fixes for particularly sensitive bugs (such as those that might lead to privilege escalations) may need to be coordinated with the private linux-distros mailing list (linux-distros@vs.openwall.org) so that distribution vendors are well prepared to release a fixed kernel as soon as possible after the public disclosure of the upstream fix. This includes verifying the reported issue, testing proposed fixes, developing a fix (if none is known yet), and backporting to older kernels and other versions.
The linux-distros list can also help with assigning a CVE for your issue.
Disclosure. The linux-distros list has a strict policy of requiring reporters to post about the security issue on oss-security within 14 days of the list being contacted regardless of whether a patch is available or not. It is therefore preferable that you don’t send your initial bug report to the linux-distros list unless you already have a patch for the issue.
List rules. The main rules to be aware of when contacting the linux-distros list are:
Don’t post about issues that are already public. If your issue has a public patch, but the security impact is not generally known, then you may still post about it.
The submitter can suggest an embargo end-date, but as a rule, embargoes should not be longer than 7 days, or at most 14 days in exceptional cases. Keep in mind that vendors may prefer to release new kernel packages and/or updates Tuesday through Thursday.
When the embargo ends, the issue must be disclosed immediately on the oss-security list (see below).
Prefix your subject with the string “[vs]” to avoid getting rejected by the spam filter.
For the full list of rules, see: https://oss-security.openwall.org/wiki/mailing-lists/distros#list-policy-and-instructions-for-reporters
Confidentiality. Please note that, as opposed to the security list, any and all material submitted to the list must be made public once the security issue is publicly disclosed, so please do not post information to the linux-distros list that cannot be made public.
Contacting the oss-security list¶
When your security issue is public, or you wish to make your issue public, you can write to the oss-security list (oss-security@lists.openwall.com). This is a public list (anybody can subscribe and view the list archives) and it is not restricted to Linux kernel issues.
The oss-security list typically does not assign CVEs or accept requests for CVE assignments.
List rules. Please do not cross-post to other lists when writing to this list. Make sure to read the other list rules before posting: https://oss-security.openwall.org/wiki/mailing-lists/oss-security .