文章介绍了Linux内核安全工作的流程，特别是关于CVE（常见漏洞披露）的发布机制。作者Greg K-H提到，虽然外界关注"安全漏洞"，但Linux内核安全处理过程并不广为人知。他曾在2023年就此主题进行演讲，现在通过文字再次说明，以帮助人们理解Linux内核CNA（CVE编号机构）如何发布CVE。这是关于Linux内核CVE发布流程系列文章的一部分。

Linux内核安全工作机制解析

本文由Greg K-H撰写于2026年1月2日，详细阐述了Linux内核安全团队的工作机制及其核心理念。以下是核心内容提炼：

一、安全团队运作原则 1. 响应式工作模式：由内核开发者组成的非官方团队专注于处理已报告的安全问题，不进行任何公开声明。 2. 独立运作机制：安全团队与CVE编号分配团队相互独立，成员均以个人身份参与，不受雇主要求约束。 3. 保密要求：成员在问题解决前不得向雇主或第三方透露任何讨论内容。

二、漏洞处理流程 1. 报告规范：仅接受纯文本邮件报告，禁止HTML格式、二进制附件或邮件加密。 2. 跨部门协作：遇到不熟悉的子系统漏洞时，会邀请对应维护者加入处理流程。 3. 修复时限：修复方案确定后必须在7天内完成合并，原则上不实施任何形式的漏洞披露禁令。

三、核心安全理念 1. 漏洞平等原则：坚持"所有漏洞都是普通漏洞"的立场，拒绝特殊标注安全修复（源自2008年Linus Torvalds的著名论述）。 2. 无公告政策：基于开源特性，开发者无法预知用户的具体使用场景，因此不判断漏洞的"安全等级"。 3. 硬件漏洞特例：针对需要固件协同修复的硬件级漏洞（如Spectre），设有临时性的加密邮件列表机制。

四、历史沿革 安全团队起源于2005年的邮件讨论，由Chris Wright正式建立集中处理机制。近二十年来始终保持着"快速修复、及时发布"的工作传统。

五、特别说明 1. 不存在任何形式的漏洞预披露名单 2. 所有修复都会同步到主分支和稳定版本分支 3. 随着欧盟CRA法规实施，长期漏洞隐瞒将面临法律限制

（注：原文中的导航菜单、时间戳、作者署名等非核心内容已精简，保留了技术细节和政策性论述）

评论总结：

1. 关于安全漏洞的态度争议：

• 批评者认为Linux将安全漏洞视为普通漏洞的做法不成熟且有害（评论1："Their view that security bugs are just normal bugs remains very immature and damaging"）
• 支持者认为不标记安全漏洞可以避免帮助黑客（评论4："avoid helping blackhat hackers by painting a giant neon sign"）

2. 对完全安全系统的期待：

• 有用户期待100%安全的操作系统（评论2："Sometimes I dream about a 100% secure OS"）
• 有评论指出当前安全报告流程存在矛盾（评论4："why is there a separate disclosure process for security bugs"）

3. 技术发展方面：

• 有用户讨论Linux桌面虚拟化技术的进步（评论6："things have been advancing which may finally allow a seamless virtualization experience"）
• 提到具体技术项目如wl-cross-domain-proxy和muvm（评论6）

4. 其他观点：

• 对强制加密报告政策的讽刺（评论3："please reconsider this policy as it feels counterproductive"）
• 对Docker镜像的调侃（评论5："ship a docker image without a kernel"）
• 对Greg网站未支持TLS的吐槽（评论7："Greg's own website still doesn't support TLS"）