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 | |
4fee0915 GKH |
66 | Coordination with other groups |
67 | ------------------------------ | |
68 | ||
69 | The kernel security team strongly recommends that reporters of potential | |
70 | security issues NEVER contact the "linux-distros" mailing list until | |
71 | AFTER discussing it with the kernel security team. Do not Cc: both | |
72 | lists at once. You may contact the linux-distros mailing list after a | |
73 | fix has been agreed on and you fully understand the requirements that | |
74 | doing so will impose on you and the kernel community. | |
75 | ||
76 | The different lists have different goals and the linux-distros rules do | |
77 | not contribute to actually fixing any potential security problems. | |
49978be7 KC |
78 | |
79 | CVE assignment | |
80 | -------------- | |
81 | ||
3c1897ae GKH |
82 | The security team does not assign CVEs, nor do we require them for |
83 | reports or fixes, as this can needlessly complicate the process and may | |
84 | delay the bug handling. If a reporter wishes to have a CVE identifier | |
85 | assigned, they should find one by themselves, for example by contacting | |
86 | MITRE directly. However under no circumstances will a patch inclusion | |
87 | be delayed to wait for a CVE identifier to arrive. | |
49978be7 | 88 | |
9d85025b MCC |
89 | Non-disclosure agreements |
90 | ------------------------- | |
1da177e4 LT |
91 | |
92 | The Linux kernel security team is not a formal body and therefore unable | |
93 | to enter any non-disclosure agreements. |