The existing information about CVE assignment requests and coordinated disclosure fits much better in these new sections, since that's what these lists are for. Keep just a reminder in the security list section. Signed-off-by: Vegard Nossum <vegard.nossum@xxxxxxxxxx> --- Documentation/process/security-bugs.rst | 92 ++++++++++++++++++------- 1 file changed, 67 insertions(+), 25 deletions(-) diff --git a/Documentation/process/security-bugs.rst b/Documentation/process/security-bugs.rst index fb156d146c42..2dd6569a7abb 100644 --- a/Documentation/process/security-bugs.rst +++ b/Documentation/process/security-bugs.rst @@ -31,6 +31,10 @@ 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.** Once a robust patch or patchset has been developed, the release process starts. The security list strongly prefers to have these posted for review and testing on public mailing lists and merged into the @@ -68,28 +72,66 @@ 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. -Coordination ------------- - -Fixes for sensitive bugs, such as those that might lead to privilege -escalations, may need to be coordinated with the private -<linux-distros@xxxxxxxxxxxxxxx> mailing list so that distribution vendors -are well prepared to issue a fixed kernel upon public disclosure of the -upstream fix. Distros will need some time to test the proposed patch and -will generally request at least a few days of embargo, and vendor update -publication prefers to happen Tuesday through Thursday. When appropriate, -the security team can assist with this coordination, or the reporter can -include linux-distros from the start. In this case, remember to prefix -the email Subject line with "[vs]" as described in the linux-distros wiki: -<http://oss-security.openwall.org/wiki/mailing-lists/distros#how-to-use-the-lists> - -CVE assignment --------------- - -The security team does not normally 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 ahead of public disclosure, they will need to contact the private -linux-distros list, described above. When such a CVE identifier is known -before a patch is provided, it is desirable to mention it in the commit -message if the reporter agrees. +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@xxxxxxxxxxxxxxx) 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 +calendar 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 calendar days, or at most 14 calendar 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@xxxxxxxxxxxxxxxxxx). +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. -- 2.40.0.rc1.2.gd15644fe02
