CVEs¶
通用漏洞披露 (CVE®) 编号的开发旨在以明确的方式识别、定义和编目公开披露的安全漏洞。然而，随着时间的推移，它们在内核项目方面的作用有所下降，CVE 编号经常以不适当的方式和出于不适当的原因被分配。正因如此，内核开发社区倾向于避免使用它们。然而，持续存在的分配 CVE 和其他形式安全标识符的压力，以及内核社区之外的个人和公司持续的滥用行为，使得内核社区有必要掌控这些分配过程。
Linux 内核开发者团队确实有能力为潜在的 Linux 内核安全问题分配 CVE。此分配独立于正常的 Linux 内核安全漏洞报告流程。
Linux 内核所有已分配 CVE 的列表可在 linux-cve 邮件列表的存档中找到，具体请参阅 https://lore.kernel.org/linux-cve-announce/。若要获取已分配 CVE 的通知，请订阅该邮件列表。
流程¶
作为正常稳定版本发布流程的一部分，潜在的安全问题内核变更会由负责 CVE 编号分配的开发者识别，并自动为其分配 CVE 编号。这些分配会频繁地以公告形式发布到 linux-cve-announce 邮件列表。
请注意，由于 Linux 内核在系统中的层级，几乎任何错误都可能被利用来损害内核的安全性，但漏洞修复时通常不明显其可利用性。因此，CVE 分配团队非常谨慎，并为他们识别的任何错误修复分配 CVE 编号。这解释了 Linux 内核团队发布的 CVE 数量看似庞大的原因。
如果 CVE 分配团队遗漏了任何用户认为应分配 CVE 的特定修复，请通过 <cve@kernel.org> 联系他们，团队将与您合作处理。请注意，不应将潜在的安全问题发送到此别名，它仅用于为已发布内核树中的修复分配 CVE。如果您认为自己发现了未修复的安全问题，请遵循正常的 Linux 内核安全漏洞报告流程。
对于 Linux 内核中未修复的安全问题，不会自动分配 CVE；只有在修复可用并应用于稳定内核树后，才会自动分配，并通过原始修复的 git 提交 ID 进行跟踪。如果任何人在问题通过提交解决之前希望分配 CVE，请通过 <cve@kernel.org> 联系内核 CVE 分配团队，从他们保留的标识符批次中获取一个标识符。
对于在 Stable/LTS 内核团队目前未积极支持的内核版本中发现的任何问题，将不会分配 CVE。目前受支持的内核分支列表可在 https://linuxkernel.org.cn/releases.html 找到。
已分配 CVE 的争议¶
对特定内核变更的已分配 CVE 提出异议或修改的权限，仅属于受影响的相关子系统的维护者。此原则确保了漏洞报告的高度准确性和问责制。只有对子系统拥有深厚专业知识和深入了解的人员，才能有效评估所报告漏洞的有效性和范围，并确定其适当的 CVE 指定。任何未经指定权限尝试修改或争议 CVE 的行为，都可能导致混乱、不准确的报告，并最终导致系统受损。
无效的 CVE¶
如果在 Linux 内核中发现安全问题，且该内核仅由某个 Linux 发行版因其自身所做的更改而支持，或者该发行版支持的内核版本不再是 kernel.org 支持的版本之一，则 Linux 内核 CVE 团队无法分配 CVE，必须向该 Linux 发行版本身请求。
任何由内核分配 CVE 团队之外的任何组织，为正在积极支持的内核版本分配的 Linux 内核 CVE，均不应被视为有效的 CVE。请通过 <cve@kernel.org> 通知内核 CVE 分配团队，以便他们通过 CNA 修复流程来使此类条目失效。
特定 CVE 的适用性¶
由于 Linux 内核可以以多种不同方式使用，外部用户也可以通过多种不同方式访问它，或者完全无法访问，因此任何特定 CVE 的适用性由 Linux 用户自行决定，而不是由 CVE 分配团队决定。请勿联系我们试图确定任何特定 CVE 的适用性。
此外，由于源代码树非常庞大，并且任何一个系统都只使用源代码树的一小部分，因此 Linux 用户应该知道，大量的已分配 CVE 与其系统无关。
简而言之，我们不了解您的使用案例，也不了解您使用的内核部分，因此我们无法确定特定 CVE 是否与您的系统相关。
一如既往，最好接受所有已发布的内核更改，因为它们是由许多社区成员作为一个统一整体进行测试的，而不是单独挑选的更改。另请注意，对于许多错误，整体问题的解决方案并非来自单一更改，而是来自许多相互叠加的修复的总和。理想情况下，所有问题的所有修复都将分配 CVE，但有时我们会未能注意到某些修复，因此请假定一些未分配 CVE 的更改可能也值得采用。