| 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 <[email protected]>
|
| 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 <[email protected]> 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 <[email protected]> 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 |
|