一个 Linux 内核本地提权漏洞，已经在 6.18.22、6.19.12、7.0 修了。
但更常见于服务器和基础设施里的 longterm 分支，比如 6.12、6.6、6.1、5.15、5.10，当时还没看到上游 stable 修复。更麻烦的是，本次没有提前通知 linux-distros 邮件列表。
这就是 CopyFail（CVE-2026-31431）最值得盯的地方。它不只是一个“等补丁”的漏洞，而是把 Linux 内核安全披露和发行版响应之间的缝，又撕开了一次。
CopyFail 到底是什么，哪些信息已经能确定
邮件讨论里，有人把 CopyFail 称为近期最严重的 “make-me-root” 类内核漏洞之一。说白了：本地用户可能借它提权到 root。
边界也要先画清。它不是远程提权。现有材料也不能支撑“所有老 LTS 内核都已确认可利用”这种说法。
目前能确认的关键信息是这些：
| 项目 | 已知信息 | 该怎么理解 |
|---|---|---|
| 漏洞编号 | CVE-2026-31431，CopyFail | Linux kernel 本地提权漏洞 |
| 风险性质 | 被讨论者称为近期严重的 make-me-root 类漏洞之一 | 对多用户、共享、容器宿主机场景更敏感 |
| 引入来源 | 问题来自 4.14 时代提交 72548b093ee3 | 理论影响范围可能覆盖多条老内核线 |
| 已知修复 | 6.18.22、6.19.12、7.0 已有修复 | 新分支先拿到补丁 |
| longterm 状态 | 6.12、6.6、6.1、5.15、5.10 当时未见上游 stable 修复 | 旧分支需要等待适配、回移植或发行版处理 |
| 发行版预警 | Sam James 说明，本次没有提交到 linux-distros ML | 发行版没有提前 heads-up |
| Gentoo 临时动作 | 拟禁用 authencesn 模块 | 因旧分支回移植不干净，涉及 API 变化 |
从 4.14 时代引入这一点看，老内核线有受影响可能。但具体到某个发行版、某个配置、某个内核包，仍要看上游适配和发行版公告。
这类漏洞最容易被写歪。它严重，但不能写成远程打穿；它可能影响老线，但不能把“可能”写成“确认”。
真正刺眼的是：发行版没有提前预警
Sam James 在邮件里说得很直：除非报告者主动把问题提交到 linux-distros 邮件列表，否则发行版不会收到预警。本次没有。
这不是 embargo 被破坏。也不能简单扣成某个组织失职。
它更像当前流程的自然结果：内核修复先进 stable，公开信息出来后，发行版再追补丁、判影响、做回移植、发公告、安排发布。
对上游来说，这套流程有它的合理性。Linux kernel 补丁量巨大，不可能把每个安全修复都包装成发行版友好的应急流程。报告者也未必愿意，或者未必知道要走 linux-distros。
但对发行版来说，问题就很硬。
安全团队不能只说“上游已经修了”。他们要回答四件事：
- 自家内核包是否受影响；
- 哪些配置或模块触发风险；
- 补丁能不能干净回移植；
- 临时缓解会不会打坏用户 workload。
Gentoo 拟禁用 authencesn 模块，就是一个典型选择。它不优雅，但现实。旧分支 API 变化导致回移植不干净时，先做可控缓解，往往比硬塞补丁更稳。
我不觉得这丢人。真正难看的是：最靠近用户的人，常常最晚拿到确定信息。
“天下熙熙，皆为利来。”放在开源安全里，这个“利”不只指钱，也指时间、责任边界、声誉和谁来背回归风险。上游要快，发行版要稳，用户要别炸机器。目标接近，账却不在一张表上。
CopyFail 照出来的，就是这张账。
受影响的人该怎么动，不该怎么猜
最该紧张的不是普通桌面用户，而是两类人。
一类是 Linux 发行版维护者和安全响应人员。现在要做的不是等 CVE 标题发酵，而是尽快核对自家内核树：修复是否已进包，旧分支能否回移植，authencesn 相关模块是否需要临时处理，公告措辞能不能把“可能影响”和“确认影响”分开。
另一类是依赖 longterm 内核的服务器和基础设施运维。尤其是共享主机、容器宿主机、多用户登录环境、企业内网跳板机。这里的本地提权不小。攻击者一旦已有低权限入口，root 就是下一层门。
更实际的动作很朴素：
| 对象 | 现在该做什么 | 不该做什么 |
|---|---|---|
| 发行版维护者 / 安全团队 | 查内核分支、评估回移植、准备公告和临时 workaround | 只引用上游新版本号，忽略旧分支状态 |
| 服务器 / 基础设施运维 | 确认正在运行的内核线，跟随发行版安全公告，评估禁用相关模块、隔离多用户环境、安排补丁窗口 | 看到“本地提权”就降级成小风险 |
| 依赖 longterm 的团队 | 把补丁可得性、回归测试、临时缓解纳入变更计划 | 默认 longterm 等于安全保险箱 |
长期内核的价值是稳定，不是免疫。
这里要有一个现实约束：longterm 分支越老，补丁越可能不干净。代码上下文变了，API 变了，测试矩阵也变了。安全修复不是复制粘贴。
这有点像铁路老线维护。新线速度快，老线覆盖广。事故不一定发生在最先进的地方，常常发生在最难改、最不敢乱动、但每天都有人跑的地方。
所以接下来最该看的，不是社交平台上谁把 CopyFail 说得更吓人。
看三件事就够了：
- 上游 stable 是否把修复推进到 6.12、6.6、6.1、5.15、5.10 等 longterm；
- 各发行版安全公告如何判断受影响范围和默认配置；
- 临时禁用 authencesn 之类 workaround 是否会带来功能影响或回归风险。
CopyFail 的补丁会继续铺开。技术债也会继续摊开。
这次真正刺眼的，不是 Linux 内核出了一个洞。大工程一定会有洞。刺眼的是，披露流程让发行版和用户又一次站在公开补丁之后，靠反应速度补制度缺口。
开源世界不能变成层层审批的官僚机器。但把发行版长期放在补丁竞速的下游，也不是成熟生态该接受的常态。