Security bugs¶
Linux kernel developers take security very seriously. As such, we’dlike to know when a security bug is found so that it can be fixed anddisclosed as quickly as possible. Please report security bugs to theLinux kernel security team.
The security team and maintainers almost always require additionalinformation beyond what was initially provided in a report and rely onactive and efficient collaboration with the reporter to perform furthertesting (e.g., verifying versions, configuration options, mitigations, orpatches). Before contacting the security team, the reporter must ensurethey are available to explain their findings, engage in discussions, andrun additional tests. Reports where the reporter does not respond promptlyor cannot effectively discuss their findings may be abandoned if thecommunication does not quickly improve.
As it is with any bug, the more information provided the easier itwill be to diagnose and fix. Please review the procedure outlined in‘Reporting issues’ if you are unclear about whatinformation is helpful. Any exploit code is very helpful and will notbe released without consent from the reporter unless it has already beenmade public.
The Linux kernel security team can be contacted by email at<security@kernel.org>. This is a private list of security officerswho will help verify the bug report and develop and release a fix.If you already have a fix, please include it with your report, asthat can speed up the process considerably. It is possible that thesecurity team will bring in extra help from area maintainers tounderstand and fix the security vulnerability.
Please send plain text emails without attachments where possible.It is much harder to have a context-quoted discussion about a complexissue if all the details are hidden away in attachments. Think of it like aregular patch submission(even if you don’t have a patch yet): describe the problem and impact, listreproduction 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 Coordinationbelow.
Once a robust fix has been developed, the release process starts. Fixesfor publicly known bugs are released immediately.
Although our preference is to release fixes for publicly undisclosed bugsas soon as they become available, this may be postponed at the request ofthe reporter or an affected party for up to 7 calendar days from the startof the release process, with an exceptional extension to 14 calendar daysif it is agreed that the criticality of the bug requires more time. Theonly valid reason for deferring the publication of a fix is to accommodatethe logistics of QA and large scale rollouts which require releasecoordination.
While embargoed information may be shared with trusted individuals inorder to develop a fix, such information will not be published alongsidethe fix or on any other disclosure channel without the permission of thereporter. This includes but is not limited to the original bug reportand followup discussions (if any), exploits, CVE information or theidentity of the reporter.
In other words our only interest is in getting bugs fixed. All otherinformation submitted to the security list and any followup discussionsof the report are treated confidentially even after the embargo has beenlifted, 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 coordinatingdisclosure between operating system vendors. Coordination is usuallyhandled by the “linux-distros” mailing list and disclosure by thepublic “oss-security” mailing list, both of which are closely relatedand 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 sincethe 3 lists pursue different goals. Coordinating between the kernelsecurity team and other teams is difficult since for the kernel securityteam occasional embargoes (as subject to a maximum allowed number ofdays) start from the availability of a fix, while for “linux-distros”they start from the initial post to the list regardless of theavailability of a fix.
As such, the kernel security team strongly recommends that as a reporterof a potential security issue you DO NOT contact the “linux-distros”mailing list UNTIL a fix is accepted by the affected code’s maintainersand you have read the distros wiki page above and you fully understandthe requirements that contacting “linux-distros” will impose on you andthe kernel community. This also means that in general it doesn’t makesense to Cc: both lists at once, except maybe for coordination if andwhile an accepted fix has not yet been merged. In other words, until afix is accepted do not Cc: “linux-distros”, and after it’s merged do notCc: the kernel security team.
CVE assignment¶
The security team does not assign CVEs, nor do we require them forreports or fixes, as this can needlessly complicate the process and maydelay the bug handling. If a reporter wishes to have a CVE identifierassigned for a confirmed issue, they can contact thekernel CVEassignment team to obtain one.
Non-disclosure agreements¶
The Linux kernel security team is not a formal body and therefore unableto enter any non-disclosure agreements.