|
| 1 | +==== |
| 2 | +CVEs |
| 3 | +==== |
| 4 | + |
| 5 | +Common Vulnerabilities and Exposure (CVE®) numbers were developed as an |
| 6 | +unambiguous way to identify, define, and catalog publicly disclosed |
| 7 | +security vulnerabilities. Over time, their usefulness has declined with |
| 8 | +regards to the kernel project, and CVE numbers were very often assigned |
| 9 | +in inappropriate ways and for inappropriate reasons. Because of this, |
| 10 | +the kernel development community has tended to avoid them. However, the |
| 11 | +combination of continuing pressure to assign CVEs and other forms of |
| 12 | +security identifiers, and ongoing abuses by individuals and companies |
| 13 | +outside of the kernel community has made it clear that the kernel |
| 14 | +community should have control over those assignments. |
| 15 | + |
| 16 | +The Linux kernel developer team does have the ability to assign CVEs for |
| 17 | +potential Linux kernel security issues. This assignment is independent |
| 18 | +of the :doc:`normal Linux kernel security bug reporting |
| 19 | +process<../process/security-bugs>`. |
| 20 | + |
| 21 | +A list of all assigned CVEs for the Linux kernel can be found in the |
| 22 | +archives of the linux-cve mailing list, as seen on |
| 23 | +https://lore.kernel.org/linux-cve-announce/. To get notice of the |
| 24 | +assigned CVEs, please `subscribe |
| 25 | +<https://subspace.kernel.org/subscribing.html>`_ to that mailing list. |
| 26 | + |
| 27 | +Process |
| 28 | +======= |
| 29 | + |
| 30 | +As part of the normal stable release process, kernel changes that are |
| 31 | +potentially security issues are identified by the developers responsible |
| 32 | +for CVE number assignments and have CVE numbers automatically assigned |
| 33 | +to them. These assignments are published on the linux-cve-announce |
| 34 | +mailing list as announcements on a frequent basis. |
| 35 | + |
| 36 | +Note, due to the layer at which the Linux kernel is in a system, almost |
| 37 | +any bug might be exploitable to compromise the security of the kernel, |
| 38 | +but the possibility of exploitation is often not evident when the bug is |
| 39 | +fixed. Because of this, the CVE assignment team is overly cautious and |
| 40 | +assign CVE numbers to any bugfix that they identify. This |
| 41 | +explains the seemingly large number of CVEs that are issued by the Linux |
| 42 | +kernel team. |
| 43 | + |
| 44 | +If the CVE assignment team misses a specific fix that any user feels |
| 45 | +should have a CVE assigned to it, please email them at <cve@kernel.org> |
| 46 | +and the team there will work with you on it. Note that no potential |
| 47 | +security issues should be sent to this alias, it is ONLY for assignment |
| 48 | +of CVEs for fixes that are already in released kernel trees. If you |
| 49 | +feel you have found an unfixed security issue, please follow the |
| 50 | +:doc:`normal Linux kernel security bug reporting |
| 51 | +process<../process/security-bugs>`. |
| 52 | + |
| 53 | +No CVEs will be automatically assigned for unfixed security issues in |
| 54 | +the Linux kernel; assignment will only automatically happen after a fix |
| 55 | +is available and applied to a stable kernel tree, and it will be tracked |
| 56 | +that way by the git commit id of the original fix. If anyone wishes to |
| 57 | +have a CVE assigned before an issue is resolved with a commit, please |
| 58 | +contact the kernel CVE assignment team at <cve@kernel.org> to get an |
| 59 | +identifier assigned from their batch of reserved identifiers. |
| 60 | + |
| 61 | +No CVEs will be assigned for any issue found in a version of the kernel |
| 62 | +that is not currently being actively supported by the Stable/LTS kernel |
| 63 | +team. A list of the currently supported kernel branches can be found at |
| 64 | +https://kernel.org/releases.html |
| 65 | + |
| 66 | +Disputes of assigned CVEs |
| 67 | +========================= |
| 68 | + |
| 69 | +The authority to dispute or modify an assigned CVE for a specific kernel |
| 70 | +change lies solely with the maintainers of the relevant subsystem |
| 71 | +affected. This principle ensures a high degree of accuracy and |
| 72 | +accountability in vulnerability reporting. Only those individuals with |
| 73 | +deep expertise and intimate knowledge of the subsystem can effectively |
| 74 | +assess the validity and scope of a reported vulnerability and determine |
| 75 | +its appropriate CVE designation. Any attempt to modify or dispute a CVE |
| 76 | +outside of this designated authority could lead to confusion, inaccurate |
| 77 | +reporting, and ultimately, compromised systems. |
| 78 | + |
| 79 | +Invalid CVEs |
| 80 | +============ |
| 81 | + |
| 82 | +If a security issue is found in a Linux kernel that is only supported by |
| 83 | +a Linux distribution due to the changes that have been made by that |
| 84 | +distribution, or due to the distribution supporting a kernel version |
| 85 | +that is no longer one of the kernel.org supported releases, then a CVE |
| 86 | +can not be assigned by the Linux kernel CVE team, and must be asked for |
| 87 | +from that Linux distribution itself. |
| 88 | + |
| 89 | +Any CVE that is assigned against the Linux kernel for an actively |
| 90 | +supported kernel version, by any group other than the kernel assignment |
| 91 | +CVE team should not be treated as a valid CVE. Please notify the |
| 92 | +kernel CVE assignment team at <cve@kernel.org> so that they can work to |
| 93 | +invalidate such entries through the CNA remediation process. |
| 94 | + |
| 95 | +Applicability of specific CVEs |
| 96 | +============================== |
| 97 | + |
| 98 | +As the Linux kernel can be used in many different ways, with many |
| 99 | +different ways of accessing it by external users, or no access at all, |
| 100 | +the applicability of any specific CVE is up to the user of Linux to |
| 101 | +determine, it is not up to the CVE assignment team. Please do not |
| 102 | +contact us to attempt to determine the applicability of any specific |
| 103 | +CVE. |
| 104 | + |
| 105 | +Also, as the source tree is so large, and any one system only uses a |
| 106 | +small subset of the source tree, any users of Linux should be aware that |
| 107 | +large numbers of assigned CVEs are not relevant for their systems. |
| 108 | + |
| 109 | +In short, we do not know your use case, and we do not know what portions |
| 110 | +of the kernel that you use, so there is no way for us to determine if a |
| 111 | +specific CVE is relevant for your system. |
| 112 | + |
| 113 | +As always, it is best to take all released kernel changes, as they are |
| 114 | +tested together in a unified whole by many community members, and not as |
| 115 | +individual cherry-picked changes. Also note that for many bugs, the |
| 116 | +solution to the overall problem is not found in a single change, but by |
| 117 | +the sum of many fixes on top of each other. Ideally CVEs will be |
| 118 | +assigned to all fixes for all issues, but sometimes we will fail to |
| 119 | +notice fixes, therefore assume that some changes without a CVE assigned |
| 120 | +might be relevant to take. |
| 121 | + |
0 commit comments