Commit | Line | Data |
---|---|---|
609d99a3 MCC |
1 | .. _securitybugs: |
2 | ||
1d7078d4 MCC |
3 | Security bugs |
4 | ============= | |
5 | ||
1da177e4 LT |
6 | Linux kernel developers take security very seriously. As such, we'd |
7 | like to know when a security bug is found so that it can be fixed and | |
8 | disclosed as quickly as possible. Please report security bugs to the | |
9 | Linux kernel security team. | |
10 | ||
9d85025b MCC |
11 | Contact |
12 | ------- | |
1da177e4 LT |
13 | |
14 | The Linux kernel security team can be contacted by email at | |
15 | <security@kernel.org>. This is a private list of security officers | |
16 | who will help verify the bug report and develop and release a fix. | |
49978be7 KC |
17 | If you already have a fix, please include it with your report, as |
18 | that can speed up the process considerably. It is possible that the | |
19 | security team will bring in extra help from area maintainers to | |
20 | understand and fix the security vulnerability. | |
1da177e4 LT |
21 | |
22 | As it is with any bug, the more information provided the easier it | |
23 | will be to diagnose and fix. Please review the procedure outlined in | |
da514157 | 24 | 'Documentation/admin-guide/reporting-issues.rst' if you are unclear about what |
49978be7 KC |
25 | information is helpful. Any exploit code is very helpful and will not |
26 | be released without consent from the reporter unless it has already been | |
27 | made public. | |
1da177e4 | 28 | |
dbf35499 KC |
29 | Please send plain text emails without attachments where possible. |
30 | It is much harder to have a context-quoted discussion about a complex | |
31 | issue if all the details are hidden away in attachments. Think of it like a | |
32 | :doc:`regular patch submission <../process/submitting-patches>` | |
33 | (even if you don't have a patch yet): describe the problem and impact, list | |
34 | reproduction steps, and follow it with a proposed fix, all in plain text. | |
35 | ||
14fdc2c5 WD |
36 | Disclosure and embargoed information |
37 | ------------------------------------ | |
38 | ||
39 | The security list is not a disclosure channel. For that, see Coordination | |
40 | below. | |
41 | ||
544b03da WD |
42 | Once a robust fix has been developed, the release process starts. Fixes |
43 | for publicly known bugs are released immediately. | |
44 | ||
45 | Although our preference is to release fixes for publicly undisclosed bugs | |
46 | as soon as they become available, this may be postponed at the request of | |
47 | the reporter or an affected party for up to 7 calendar days from the start | |
48 | of the release process, with an exceptional extension to 14 calendar days | |
49 | if it is agreed that the criticality of the bug requires more time. The | |
50 | only valid reason for deferring the publication of a fix is to accommodate | |
51 | the logistics of QA and large scale rollouts which require release | |
52 | coordination. | |
14fdc2c5 | 53 | |
806654a9 | 54 | While embargoed information may be shared with trusted individuals in |
14fdc2c5 WD |
55 | order to develop a fix, such information will not be published alongside |
56 | the fix or on any other disclosure channel without the permission of the | |
57 | reporter. This includes but is not limited to the original bug report | |
58 | and followup discussions (if any), exploits, CVE information or the | |
59 | identity of the reporter. | |
60 | ||
61 | In other words our only interest is in getting bugs fixed. All other | |
62 | information submitted to the security list and any followup discussions | |
63 | of the report are treated confidentially even after the embargo has been | |
64 | lifted, in perpetuity. | |
1da177e4 | 65 | |
49978be7 KC |
66 | Coordination |
67 | ------------ | |
68 | ||
69 | Fixes for sensitive bugs, such as those that might lead to privilege | |
70 | escalations, may need to be coordinated with the private | |
71 | <linux-distros@vs.openwall.org> mailing list so that distribution vendors | |
72 | are well prepared to issue a fixed kernel upon public disclosure of the | |
73 | upstream fix. Distros will need some time to test the proposed patch and | |
74 | will generally request at least a few days of embargo, and vendor update | |
75 | publication prefers to happen Tuesday through Thursday. When appropriate, | |
76 | the security team can assist with this coordination, or the reporter can | |
77 | include linux-distros from the start. In this case, remember to prefix | |
78 | the email Subject line with "[vs]" as described in the linux-distros wiki: | |
79 | <http://oss-security.openwall.org/wiki/mailing-lists/distros#how-to-use-the-lists> | |
80 | ||
81 | CVE assignment | |
82 | -------------- | |
83 | ||
84 | The security team does not normally assign CVEs, nor do we require them | |
85 | for reports or fixes, as this can needlessly complicate the process and | |
86 | may delay the bug handling. If a reporter wishes to have a CVE identifier | |
87 | assigned ahead of public disclosure, they will need to contact the private | |
88 | linux-distros list, described above. When such a CVE identifier is known | |
89 | before a patch is provided, it is desirable to mention it in the commit | |
14fdc2c5 | 90 | message if the reporter agrees. |
49978be7 | 91 | |
9d85025b MCC |
92 | Non-disclosure agreements |
93 | ------------------------- | |
1da177e4 LT |
94 | |
95 | The Linux kernel security team is not a formal body and therefore unable | |
96 | to enter any non-disclosure agreements. |