github.com/google/syzkaller@v0.0.0-20251211124644-a066d2bc4b02/docs/translations/zh_CN/linux/reporting_kernel_bugs.md (about)

     1  > [!WARNING]
     2  >
     3  > **请注意，这是社区驱动的官方 syzkaller 文档翻译。当前文档的最新版本（英文版）可在 [docs/linux/reporting_kernel_bugs.md](/docs/linux/reporting_kernel_bugs.md) 中找到。**
     4  
     5  # 报告 Linux 内核错误
     6  
     7  在报告错误之前，请确保没有其他人已经重复报告过它. 最简单的方法是在 [syzkaller 邮件列表](https://groups.google.com/forum/#!forum/syzkaller), [syzkaller-bugs 邮件列表](https://groups.google.com/forum/#!forum/syzkaller-bugs) 和 [syzbot dashboard](https://syzkaller.appspot.com/upstream) 中搜索内核栈跟踪中存在的关键栈帧。
     8  
     9  请将发现的错误报告给 Linux 内核维护人员。要找出负责特定内核子系统的维护者列表，请使用 [get_maintainer.pl](https://github.com/torvalds/linux/blob/master/scripts/get_maintainer.pl) 脚本：`./scripts/get_maintainer.pl -f guilty_file.c`。请将 `syzkaller@googlegroups.com` 添加到抄送列表。确保在报告中明确指出发生错误的确切内核分支和版本号。因为许多内核邮件列表不接受 HTML 格式的邮件，所以在发送报告时请使用纯文本模式。
    10  
    11  在提交报告前需要字斟句酌。如今，Linux 维护者被日益增加的 bug 报告所淹没，因此仅仅增加报告的提交量无助于解决内核错误本身。因此，您的报告越详细越具有可操作性，解决它的可能性就越大。请注意，人们更关心内核崩溃，如释放后使用（use-after-frees）或严重错误（panics）而非仅仅是 INFO 错误信息或者类似的信息，除非从报告中清楚地指出了到底在哪里出现了什么具体问题。如果有停顿（stalls）或挂起异常（hangs），只有在它们发生得足够频繁或能够定位错误原因时才报告它们。
    12  
    13  总体而言，没有重现用例 (reproducers) 的错误不太可能被分类和修复。如果内核错误是可复现的，请提交包括重现用例（如果可能的话，使用 C 源代码，否则使用 syzkaller 程序）和编译内核使用的 `.config` 文件。如果重现用例仅以 syzkaller 程序的形式提供，请在您的报告中给出链接说明[如何执行它们](/docs/reproducing_crashes.md)。如果您手动运行，请检查重现用例是否正常工作。Syzkaller 试图简化复制器，但结果可能并不理想。您可以尝试手动简化或注释重现用例，这极大地帮助内核开发人员找出错误发生的原因。
    14  
    15  如果您想进一步做出贡献，您可以尝试了解错误并尝试自行修复内核程序。如果您无法找到正确的修复方法，但对错误有一定的了解，也请在报告中添加您的想法和结论，这将为内核开发人员节省时间。
    16  
    17  ## 报告安全漏洞
    18  
    19  如果您确信发现的内核错误会带来潜在的安全威胁，请考虑按照以下说明进行操作。请注意，这些说明是基于我正在进行的工作和对当前过程的理解。 现在 [这里](http://seclists.org/oss-sec/2017/q3/242).正在讨论这个说明。
    20  
    21  如果您不想陷入这个复杂的披露过程，您可以：
    22  
    23  1. 私下将错误报告给 `security@kernel.org`. 在这种情况下，它应该在上游内核中修复，但不能保证错误修复会传播到稳定版或发行版内核。此清单上的最长禁止公开披露期限为 7 天。
    24  2. 私下向例如 Red Hat (`secalert@redhat.com`) 或者 SUSE (`security@suse.com`) 等供应商报告错误. 他们会修复错误，分配 CVE，并通知其他供应商。这些名单上的最长禁运期限 embargo 为 5 周。
    25  3. 将该错误公开报告给 `oss-security@lists.openwall.com`。
    26  
    27  如果您想自己处理披露，请阅读下文。
    28  
    29  用于报告和披露 Linux 内核安全问题的三个主要邮件列表是 `security@kernel.org`, `linux-distros@vs.openwall.org` 和 `oss-security@lists.openwall.com`.
    30  这些列表的指南链接如下，在向这些列表发送任何内容之前，请仔细阅读它们。
    31  
    32  1. `security@kernel.org` - https://www.kernel.org/doc/html/latest/admin-guide/security-bugs.html
    33  2. `linux-distros@vs.openwall.org` - http://oss-security.openwall.org/wiki/mailing-lists/distros
    34  3. `oss-security@lists.openwall.com` - http://oss-security.openwall.org/wiki/mailing-lists/oss-security
    35  
    36  ### 报告次要安全漏洞
    37  
    38  要报告次要安全漏洞（例如本地拒绝服务（DOS）或本地信息泄漏），您应当：
    39  
    40  1. 如上所述，向内核开发人员公开报告错误，并等待错误修复被提交。或者，您可以自己开发并发送修复程序。
    41  2. 通过[网页表单](https://cveform.mitre.org/)向 MITRE 请求 CVE。描述内核错误的详细信息，并在请求中添加指向修复的链接 (`patchwork.kernel.org`, `git.kernel.org` 或者 `github.com`).
    42  3. 分配 CVE 后，将内核错误详细信息、CVE 编号和修复链接发送到 `oss-security@lists.openwall.com`.
    43  
    44  ### 报告主要安全漏洞
    45  
    46  要报告主要安全漏洞（例如本地提权（LPE）、远程拒绝服务、远程信息泄漏或远程代码执行（RCE）），您应当：
    47  
    48  1. 理解错误原因，如果可能，请开发修复漏洞的补丁。（可选）开发漏洞 PoC（proof-of-concept）。
    49  2. 通知 `security@kernel.org`：
    50      * 描述漏洞详细信息，包括建议的补丁和漏洞利用（可选）。
    51      * 要求 7 天的 embargo。
    52      * 与 `security@kernel.org` 的成员一起处理补丁.
    53  3. 通知 `linux-distros@vs.openwall.org`：
    54      * 描述漏洞详细信息，包括建议的补丁和漏洞利用（可选）。
    55      * 要求他们分配一个 CVE 编号。
    56      * 要求 7 天的 embargo。
    57  4. 等待 7 天，让 linux 发行版应用补丁。
    58  5. 要求 `linux-distros@vs.openwall.org` 公开 CVE 描述并推出更新的内核.
    59  6. 将漏洞修复发送到上游：
    60      * 在提交消息中提及 CVE 编号。
    61      * 在提交消息中提及 syzkaller。
    62  7. 通知 `oss-security@lists.openwall.com`：
    63      * 描述漏洞详细信息，包括指向已提交补丁的链接。
    64  8. 等待 1-3 天，让大众更新系统内核。
    65  9. （可选）在 `oss-security@lists.openwall.com` 上发布漏洞利用方法。
    66  
    67  几点说明：
    68  
    69  * 理想情况下，应当同时向 `security@kernel.org` 和 `linux-distros@vs.openwall.org` 报告。
    70  * 在与 `security@kernel.org` 成员和上游维护者一起开发补丁时，请让 linux-distros 了解进度。
    71  * 理想情况下，CVE 描述发布、发行版更新、上游提交和向 `oss-security@lists.openwall.com` 发布通知应该同时完成。最差情况下，这些操作都应该在同一天完成。
    72  * 一旦问题被公开（如向上游提交补丁、发布 CVE 描述等），必须立即向 `oss-security@lists.openwall.com` 报告。
    73  
    74  [点击此处](http://seclists.org/oss-sec/2016/q4/607)可查看 `oss-security@lists.openwall.com` 上的一个本地提权公告样例，但是时间线看起来并不正确。公开的公告应该在补丁提交给 netdev 后立即发出。