English

安全漏洞

Linux 内核开发者非常重视安全性。因此，我们希望在发现安全漏洞时能够知悉，以便尽快对其进行修复和披露。

准备您的报告

与任何错误报告一样，安全漏洞报告需要开发者进行大量的分析工作，因此您能分享的关于该问题的信息越多越好。如果您不清楚哪些信息有用，请查阅 报告问题 中概述的流程。以下信息在任何安全漏洞报告中都是绝对必要的：

  • 受影响的内核版本范围：如果没有版本指示，您的报告将不会被处理。很大一部分报告针对的是已经修复的漏洞，因此在最近的版本（开发树或最新稳定版）上验证漏洞极其重要，至少要验证代码自检测到该漏洞的版本以来是否发生了变化。

  • 问题描述：必须提供问题的详细描述，包括显示其表现的追踪信息，以及为什么您认为所观察到的行为是内核中的问题。

  • 复现程序：开发者需要能够复现该问题，才能认为修复是有效的。这包括触发问题的方法和确认其发生的方法。需要一个低复杂度依赖的复现程序（源代码、shell 脚本、指令序列、文件系统镜像等）。不接受仅包含二进制的可执行文件。可工作的攻击代码（exploit）非常有用，并且在未经报告者同意之前不会发布，除非它们已经公开。从定义上讲，如果一个问题无法被复现，它就不可被利用，因此它不是一个安全漏洞。

  • 条件：如果该漏洞依赖于某些配置选项、sysctl、权限、时序、代码修改等，应当予以指明。

此外，以下信息也是非常期望的：

  • 疑似漏洞位置：疑似存在漏洞的文件名和函数非常重要，至少有助于将报告转发给合适的维护者。当无法确定时（例如“每次我运行此命令时系统都会冻结”），安全团队将协助确定漏洞的来源。

  • 建议的修复方案：分析过源码中漏洞原因的报告者几乎总是对如何修复它有准确的想法，因为他们花了很多时间研究它及其影响。提出一个经过测试的修复方案将为维护者节省大量时间，即使该修复方案最终不正确，因为它有助于理解漏洞。在提出经过测试的修复方案时，请务必将其格式化为可以立即合并的形式（参见 提交补丁：将代码合并入内核的必备指南）。如果被接受，这将节省一些来回沟通的交流，并且您将因发现并修复此问题而获得署名。请注意，在这种情况下，只需要一个 Signed-off-by: 标签，当报告者和作者是同一人时，不需要 Reported-by: 标签。

  • 缓解措施：在漏洞分析过程中，往往会出现一些缓解该问题的方法。分享这些方法非常有用，因为在最终用户应用修复程序所需的时间内，它们有助于保护终端用户的安全。

什么算作安全漏洞

绝大多数漏洞都以公开方式处理，这非常重要，因为这样可以吸引尽可能广泛的受众并找到最佳解决方案。从本质上讲，在少数参与者之间通过闭门讨论处理的漏洞，不太可能产生最佳的修复方案（例如，存在遗漏有效用例的风险、测试能力受限）。

事实证明，通过安全团队报告的大多数漏洞只是普通漏洞，由于缺乏对 Linux 内核威胁模型的了解（如 Linux 内核威胁模型 中所述），被不恰当地定性为了安全漏洞，它们本应该通过 报告问题 中描述的正常渠道发送。

安全邮件列表的存在是为了处理紧急漏洞，这些漏洞赋予了攻击者在正确配置的生产系统上不应拥有的能力，并且易于被利用，对许多用户构成了迫在眉睫的威胁。在报告之前，请考虑该问题是否真的在此类系统上跨越了信任边界。

如果您借助 AI 来识别漏洞，则必须将其视为公开漏洞。虽然您可能有充分的理由相信它不是公开的，但安全团队的经验表明，通过这种方式发现的漏洞往往会系统性地在多位研究人员之间同时浮现，通常在同一天。在这种情况下，请勿公开分享复现程序，因为这可能会造成意料之外的危害；只需提及有一个可用的复现程序，如果维护者需要，他们可能会私下索取。

如果您不确定某个问题是否符合条件，请倾向于私下报告：安全团队宁愿分诊一份边缘性的报告，也不愿漏掉一个真正的漏洞。然而，将普通漏洞报告给安全邮件列表并不会加快其处理速度，反而会消耗其他报告所需要的分诊（triage）能力。

确定联系人

报告安全漏洞最有效的方法是直接将其发送给受影响子系统的维护者，并抄送（Cc:）Linux 内核安全团队。在此阶段，请勿将其发送到公共列表，除非您有充分的理由认为该问题已经是公开的或极易被发现（例如：任何人都可以重复使用的广泛可用的自动化漏洞扫描工具的结果，或者使用了基于 AI 的工具）。

如果您发送的报告涉及内核中多个部分的问题（即使是相当类似的问题），请分别发送单独的邮件（想想看，维护者们不可能同时处理所有这些问题）。唯一的例外是，当某个问题涉及由完全相同的维护者子集所维护的紧密相关的部分，并且这些部分预期将通过同一个提交（commit）同时修复时，一次性报告它们可能是可以接受的。

对于大多数首次报告者来说，困难之一是弄清楚应该将报告发送给哪些收件人。在 Linux 内核中，所有官方维护者都是受信任的，因此不小心将错误的维护者包含在内的后果本质上只是给那个人增加了一点噪音，即没有什么大不了的。因此，确定维护者列表的一种合适方法（这也是内核安全官员所使用的）是依赖 get_maintainer.pl 脚本，并将其调整为仅报告维护者。当向该脚本传递一个文件名时，它会在 MAINTAINERS 文件中查找其路径，以得出相关维护者的分层列表。第一次以最精细的过滤级别调用它，大多数情况下会返回该特定文件的维护者的简短列表

$ ./scripts/get_maintainer.pl --no-l --no-r --pattern-depth 1 \
  drivers/example.c
Developer One <dev1@example.com> (maintainer:example driver)
Developer Two <dev2@example.org> (maintainer:example driver)

这两位维护者随后应收到该邮件。如果该命令没有返回任何内容，则意味着受影响的文件属于一个更广泛的子系统，因此我们应该减少其具体性

$ ./scripts/get_maintainer.pl --no-l --no-r drivers/example.c
Developer One <dev1@example.com> (maintainer:example subsystem)
Developer Two <dev2@example.org> (maintainer:example subsystem)
Developer Three <dev3@example.com> (maintainer:example subsystem [GENERAL])
Developer Four <dev4@example.org> (maintainer:example subsystem [GENERAL])

在这里，挑选前几个最具体的就足够了。当列表很长时，可以生成一个单行的、以逗号分隔的电子邮件地址列表，以便在邮件客户端的 To: 字段中使用，如下所示

$ ./scripts/get_maintainer.pl --no-tree --no-l --no-r --no-n --m \
  --no-git-fallback --no-substatus --no-rolestats --no-multiline \
  --pattern-depth 1 drivers/example.c
dev1@example.com, dev2@example.org

或者针对更广泛的列表使用这个

$ ./scripts/get_maintainer.pl --no-tree --no-l --no-r --no-n --m \
  --no-git-fallback --no-substatus --no-rolestats --no-multiline \
  drivers/example.c
dev1@example.com, dev2@example.org, dev3@example.com, dev4@example.org

如果此时您仍然难以找到正确的维护者，且仅在这种情况下，您可以仅将报告发送给 Linux 内核安全团队。您的消息将被分诊，如有必要，您将收到关于联系谁的指示。您的消息也可能会被原封不动地转发给相关的维护者。

负责任地使用 AI 来查找漏洞

提交给安全团队的漏洞报告中有相当一部分实际上是 AI 工具辅助代码审查的结果。虽然这可能是发现极少探索区域中漏洞的有效手段，但它给维护者造成了过重的负担，维护者有时由于这些报告的质量或准确性较差而被迫忽略它们。因此，报告者必须特别注意以下几个容易使这些报告变得不必要地难以处理的点

  • 长度：AI 生成的报告往往过长，包含多个章节和过多的细节。这使得很难发现重要信息，例如受影响的文件、版本和影响。请确保首先呈现清晰的问题摘要和所有关键细节。不要要求分诊工程师去浏览好几页的文本。请配置您的工具以生成简洁的、人类风格的报告。

  • 格式：大多数 AI 生成的报告充斥着 Markdown 标签。这些修饰使查找重要信息变得复杂，并且在转发或回复所涉及的引用过程中无法保留。请在发送之前，务必将您的报告转换为不带任何格式修饰的纯文本。

  • 影响评估：许多 AI 生成的报告缺乏对内核威胁模型的理解（参见 Linux 内核威胁模型），并费尽心思捏造理论上的后果。这增加了噪音并使分诊复杂化。请坚持可验证的事实（例如，“此 bug 允许任何用户获取 CAP_NET_ADMIN”），而不要枚举推测性的影响。让您的工具将本文档作为评估过程的一部分来阅读。

  • 复现程序：基于 AI 的工具通常能够生成复现程序。请务必确保您的工具提供了一个复现程序并对其进行彻底测试。如果复现程序无法工作，或者工具无法生成复现程序，那么该报告的有效性就应该受到严重质疑。请注意，由于报告将被发布到公共列表，复现程序只能应维护者的请求进行分享。

  • 提出修复方案：许多 AI 工具在编写代码方面实际上比在评估代码方面做得更好。请在报告问题之前，要求您的工具提出一个修复方案并对其进行测试。如果由于修复方案依赖于罕见的硬件或几乎灭绝的网络协议而无法测试，则该问题很可能不是安全漏洞。无论如何，如果提出了修复方案，它必须遵守 提交补丁：将代码合并入内核的必备指南 并包含一个指定引入该 bug 的提交的 ‘Fixes:’ 标签。

未能考虑这些要点会使您的报告面临被忽略的风险。

在评估报告时请运用常识。如果受影响的文件已经一年多没有被触及且由个人单独维护，那么它的使用量可能已经下降，受影响的用户几乎不存在（例如，针对非常古老的硬件的驱动程序、过时的文件系统）。在这种情况下，没有必要用不重要的报告来浪费维护者的时间。如果该问题显然微不足道且可公开发现，您应该直接将其报告给公共邮件列表。

发送报告

报告只能通过电子邮件发送。请使用一个有效的电子邮件地址，最好与您希望出现在 Reported-by 标签中的地址相同（如果有的话）。如果不确定，请先将报告发送给自己。

除了报告最初提供的信息之外，安全团队和维护者几乎总是需要额外的信息，并且依赖于与报告者的积极、高效的合作来执行进一步的测试（例如，验证版本、配置选项、缓解措施或补丁）。在联系安全团队之前，报告者必须确保他们有时间解释自己的发现、参与讨论并运行额外的测试。如果报告者未能及时回复或无法有效地讨论其发现，且沟通情况未能在短时间内改善，此类报告可能会被放弃。

报告必须发送给维护者。如果您邮件中的收件人有两位或更少，您还必须始终抄送（Cc:）Linux 内核安全团队，他们将确保邮件能够送达给正确的人员，并能够协助较小的维护者团队处理他们可能不熟悉的流程。对于较大的团队，在您的前几次报告中，或者在寻求特定帮助时（例如在一周内未收到回复而重新发送邮件时），请抄送 Linux 内核安全团队。一旦您在几次报告中熟悉了这一流程，向大团队发送邮件时就不再需要抄送安全列表了。可以通过电子邮件联系 Linux 内核安全团队：<security@kernel.org>。这是一个由安全官员组成的私密列表，他们将帮助验证漏洞报告并协助开发者进行修复工作。安全团队可能会引入来自该领域维护者的额外帮助，以理解和修复安全漏洞。

请尽可能发送不带附件的纯文本电子邮件。如果所有细节都隐藏在附件中，围绕复杂问题进行带上下文引用的讨论就会困难得多。把它想象成一个常规的补丁提交（即使你还没有补丁）：描述问题和影响、列出复现步骤，并在最后附上建议的修复方案，全部使用纯文本。特别不赞成使用 Markdown、HTML 和 RST 格式的报告，因为它们对人类来说很难阅读，并且会促使人们使用专门的查看器（有时甚至是网上的查看器），而这对于机密的安全报告来说按定义是不可接受的。请注意，某些邮件客户端默认会损坏纯文本的格式，请查阅 Linux 的电子邮件客户端信息 以获取更多信息。

披露与禁运信息

安全列表不是一个披露渠道。有关这方面的信息，请参见下文的“协调”。

一旦开发出稳健的修复方案，发布流程便告开始。针对公开已知漏洞的修复方案会立即发布。

尽管我们的首选是在未公开漏洞的修复方案可用时立即发布，但应报告者或受影响方的请求，发布时间可以从发布流程开始算起推迟最多 7 个日历日；如果经协商认为该漏洞的严重性需要更多时间，则可以作为特例延长至 14 个日历日。推迟发布修复方案的唯一正当理由是为了适应需要发布协调的 QA 和大规模部署的后勤工作。

虽然为了开发修复方案，禁运信息可能会与受信任的个人共享，但未经报告者许可，此类信息不会与修复方案一起发布，也不会在任何其他披露渠道上发布。这包括但不限于原始漏洞报告及后续讨论（如果有）、攻击代码、CVE 信息或报告者的身份。

换句话说，我们唯一的兴趣就是修复漏洞。提交给安全列表的所有其他信息以及对该报告的任何后续讨论，即使在禁运解除后，也将永久作为机密处理。

与其他小组的协调

虽然内核安全团队专注于修复漏洞，但其他小组则专注于修复发行版中的问题并在操作系统厂商之间协调披露。协调工作通常由 “linux-distros” 邮件列表处理，披露则由公开的 “oss-security” 邮件列表处理，这两者密切相关，并介绍在 linux-distros wiki 中：<https://oss-security.openwall.org/wiki/mailing-lists/distros>

请注意，由于这 3 个列表追求不同的目标，各自的政策和规则也有所不同。在内核安全团队和其他团队之间进行协调是很困难的，因为对内核安全团队而言，临时禁运（受允许的最大天数限制）从修复方案可用时算起，而对 “linux-distros” 而言，无论修复方案是否可用，它们都从首次向列表发帖时算起。

因此，内核安全团队强烈建议，作为潜在安全问题的报告者，在修复方案被受影响代码的维护者接受之前，请勿联系 “linux-distros” 邮件列表，并且您必须阅读上述发行版 wiki 页面，并完全理解联系 “linux-distros” 将对您和内核社区施加的要求。这也意味着，通常情况下，同时抄送两个列表是没有意义的，除非是为了在已接受的修复方案尚未合并期间进行协调。换句话说，在修复方案被接受之前，请勿抄送 “linux-distros”；在合并之后，请勿抄送内核安全团队。

CVE 分配

安全团队不分配 CVE，我们也不要求在报告或修复时提供 CVE，因为这可能会不必要地使流程复杂化并延迟漏洞处理。如果报告者希望为已确认的问题分配 CVE 标识符，他们可以联系 内核 CVE 分配团队 来获取一个。

保密协议

Linux 内核安全团队不是一个正式机构，因此无法签署任何保密协议。