Linux 内核新增安全漏洞认定标准与 AI 负责任使用文档

作者：Michael Larabel
发布于：2026年5月15日
原文链接：https://www.phoronix.com/news/Linux-7.1-Kernel-Docs-AI-Bugs

Linux 7.1 内核今日合并了一系列新增文档，内容涉及安全漏洞的认定标准，以及如何负责任地使用 AI 来发现内核漏洞[reference:0]。考虑到近期提交到内核的安全漏洞数量激增，且部分漏洞和错误报告完全或部分由 AI 工具发现，因此有必要增加相关文档[reference:1]。长期从事 Linux 开发的开发者 Willy Tarreau 起草了这些关于内核漏洞的补充文档[reference:2]。

关于 Linux 内核安全漏洞的认定标准，新文档指出：“让绝大多数错误被公开处理非常重要，这样才能让更多人参与进来，找到最佳解决方案。在少数参与者之间进行内部讨论时，倾向于产生不完美的修复方案（例如可能会遗漏有效的用例，或测试能力有限）[reference:3]。根据安全团队的报告，绝大多数安全漏洞实际上都是普通漏洞，只是因为报告者对 Linux 内核的威胁模型（详见 Documentation/process/threat-model.rst）缺乏了解，而被错误地标记为安全漏洞。这些报告本应通过 Documentation/admin-guide/reporting-issues.rst 中描述的常规渠道提交[reference:4]。安全邮件列表是为那些紧急漏洞设立的，这些漏洞能让攻击者在配置正确的生产系统中获得不应有的能力，且容易被利用，对众多用户构成迫在眉睫的威胁[reference:5]。在报告之前，请先考虑该问题是否真的跨越了此类系统中的信任边界。

如果你借助 AI 辅助发现了某个漏洞，则必须将其视为公开漏洞[reference:6]。即便你有合理的理由认为它并非如此，安全团队的经验表明，通过这种方式发现的漏洞，往往会同时被多名研究人员发现，甚至就在同一天。在这种情况下，不要公开分享漏洞的触发程序（reproducer），因为这可能会造成意想不到的损害；只需说明你手头有一个这样的程序，如果维护者需要，他们可能会私下向你索取[reference:7]。如果你不确定某个问题是否符合标准，宁可私下报告：安全团队宁愿处理一个模棱两可的报告，也不愿错过一个真正的漏洞[reference:8]。然而，将普通漏洞报告到安全列表并不会加快处理速度，反而会消耗本应用于处理其他报告的评估能力。[reference:9]”

关于负责任地使用 AI 来发现 Linux 内核漏洞的指引：“提交给安全团队的漏洞报告中，很大一部分实际上是 AI 工具辅助代码审查的结果[reference:10]。虽然这可能是发现鲜少被探索领域漏洞的有效手段，但也给维护者带来了过重的负担，他们有时会因为这些报告质量不高或不够准确而被迫忽略它们[reference:11]。因此，报告者必须特别注意以下几点，这些因素往往会导致这些报告处理起来异常困难：

• 篇幅：AI 生成的报告通常篇幅过长，包含多个章节和过多细节。这会使得识别重要信息（如受影响文件、版本和影响程度）变得困难[reference:12]。请确保先清晰地概述问题并提供所有关键细节。不要让评估工程师费力地扫描多页文本。配置你的工具，使其生成简洁、类人化的报告[reference:13]。
• 格式：大多数 AI 生成的报告充斥着 Markdown 标签[reference:14]。这些装饰会干扰对重要信息的查找，并且在转发或回复时无法在引用过程中保留。在发送报告之前，请务必将其转换为纯文本，并去除所有格式标记[reference:15]。
• 影响评估：许多 AI 生成的报告缺乏对内核威胁模型（请参阅 Documentation/process/threat-model.rst）的理解，进而大篇幅地臆想理论上的后果[reference:16]。这只会增加噪音，并使评估复杂化。请坚持使用可验证的事实（例如，“此漏洞允许任何用户获得 CAP_NET_ADMIN 权限”），不要列举推测性的影响。让你的工具在评估过程中阅读此文档作为参考[reference:17]。
• 触发程序（Reproducer）：AI 工具通常能够生成触发程序[reference:18]。请始终确保你的工具能提供一个，并对其进行充分测试[reference:19]。如果触发程序不起作用，或者工具无法生成，那么该报告的有效性就应该受到严重质疑。请注意，由于报告将被发布到公共邮件列表中，触发程序应仅在维护者要求时才共享[reference:20]。
• 提出修复方案：许多 AI 工具实际上更擅长编写代码而非评估代码[reference:21]。在报告问题之前，请让你的工具提出修复方案并进行测试[reference:22]。如果因为依赖稀有硬件或近乎淘汰的网络协议而无法测试该修复方案，那么该问题可能不是一个安全漏洞。无论如何，如果提出了修复方案，它必须遵守 Documentation/process/submitting-patches.rst 中的规定，并包含一个 'Fixes:' 标签，指明引入该漏洞的提交[reference:23]。
• 若忽视上述要点，你的报告可能会被忽略[reference:24]。
• 在评估报告时运用常识。如果受影响的文件已超过一年无人修改，且由单个人维护，那么很可能该代码的使用率已经下降，几乎没有用户在使用（例如，老旧硬件的驱动程序、过时的文件系统）。在这种情况下，无需为一份不重要的报告而消耗维护者的时间。如果问题非常微不足道且是公开可发现的，你应该直接将其报告到公共邮件列表。[reference:25]

所有这些由 Willy Tarreau 编写的 Linux 内核漏洞新文档都可以通过 此提交 查阅，该提交已合入 Linux Git 仓库，将在周日的 Linux 7.1-rc4 版本发布前面世[reference:26]。