安全漏洞¶
Linux 内核开发者非常重视安全性。因此，我们希望在发现安全漏洞时能及时知晓，以便能尽快修复和披露。请向 Linux 内核安全团队报告安全漏洞。
联系方式¶
可以通过电子邮件联系 Linux 内核安全团队：<security@kernel.org>。这是一个由安全官员组成的私人列表，他们将协助验证 Bug 报告并开发和发布修复程序。如果您已经有了修复程序，请在报告中附上，因为这可以大大加快处理过程。安全团队可能会引入区域维护者的额外帮助，以理解和修复安全漏洞。
与任何 Bug 一样，提供的信息越多，诊断和修复就越容易。如果您不清楚哪些信息有用，请查阅“报告问题”中概述的程序。任何利用代码都非常有用，未经报告者同意，除非已公开，否则不会发布。
请尽可能发送纯文本电子邮件，不要带附件。如果所有详细信息都隐藏在附件中，那么就很难对一个复杂问题进行上下文引用的讨论。把它想象成一个常规补丁提交（即使您还没有补丁）：描述问题和影响，列出重现步骤，然后附上建议的修复方案，所有内容都以纯文本形式。
披露和保密信息¶
安全列表不是披露渠道。有关披露，请参阅下面的“协调”。
一旦开发出健壮的修复程序，发布过程便会启动。已公开已知 Bug 的修复程序会立即发布。
尽管我们倾向于在公开未披露的 Bug 修复程序可用后立即发布，但这可能会应报告者或受影响方的请求推迟，最长可达发布过程开始后的 7 个日历日，如果经同意认为 Bug 的严重性需要更多时间，则可破例延长至 14 个日历日。推迟发布修复程序的唯一正当理由是为了配合需要发布协调的 QA 和大规模部署的物流安排。
虽然保密信息可能会与可信赖的个人共享以开发修复程序，但此类信息未经报告者许可，不会随修复程序一起发布，也不会在任何其他披露渠道发布。这包括但不限于原始 Bug 告和后续讨论（如有）、漏洞利用、CVE 信息或报告者的身份。
换句话说，我们唯一的兴趣是修复 Bug。提交给安全列表的所有其他信息以及报告的任何后续讨论都将永久保密，即使禁令解除后也是如此。
与其他组的协调¶
内核安全团队专注于修复 Bug，而其他组则专注于修复发行版中的问题并协调操作系统供应商之间的披露。“linux-distros”邮件列表通常处理协调工作，“oss-security”公共邮件列表则处理披露工作，两者都密切相关并在 linux-distros wiki 中介绍：<https://oss-security.openwall.org/wiki/mailing-lists/distros>
请注意，由于这三个列表的目标不同，其各自的政策和规则也不同。内核安全团队与其他团队之间的协调很困难，因为对于内核安全团队来说，偶尔的禁令（最多允许的天数）从修复程序可用时开始，而对于“linux-distros”来说，则从最初发布到列表时开始，无论修复程序是否可用。
因此，内核安全团队强烈建议，作为潜在安全问题的报告者，您在受影响代码的维护者接受修复程序之前，**不要**联系“linux-distros”邮件列表，并且您已阅读上述 distros wiki 页面并完全理解联系“linux-distros”将对您和内核社区施加的要求。这也意味着通常不建议同时抄送两个列表，除非在接受的修复程序尚未合并时进行协调。换句话说，在修复程序被接受之前，不要抄送“linux-distros”；在修复程序合并之后，不要抄送内核安全团队。
CVE 分配¶
安全团队不分配 CVE，我们也不要求报告或修复程序提供 CVE，因为这可能会不必要地使流程复杂化并可能延迟 Bug 处理。如果报告者希望为已确认的问题分配 CVE 标识符，他们可以联系内核 CVE 分配团队获取一个。
保密协议¶
Linux 内核安全团队不是一个正式机构，因此无法签订任何保密协议。