出品：养个闲人有限公司

Linux内核惊现"CopyFail"核弹级漏洞：9年前埋下的雷今天爆了，你的服务器可能正在裸奔

如果你的服务器还在跑Linux 5.x或6.x，立刻放下手中的咖啡。一个潜伏9年的内核级提权漏洞刚刚被公开，而官方修复补丁，还没到位。

这不是演习。CVE-2026-31431，代号CopyFail，被安全研究者称为"近年来最糟糕的本地提权漏洞之一"。从2017年的内核4.14到当下的主流LTS版本，几乎无一幸免。

一颗埋了9年的雷：CopyFail到底是什么

事情起源于Hacker News上炸开的一则安全公告。CopyFail（CVE-2026-31431）是一个Linux本地权限提升漏洞，问题代码早在2017年就随着内核4.14的一个提交潜入了系统，直到今天才被彻底曝光。

Issue introduced in 4.14 with commit 72548b093ee38a6d4f2a19e6ef1948ae05c181f7 and fixed in 6.18.22 with commit fafe0fa2995a0f7073c1c358d7d3145bcc9aedd8

Fixed in 6.19.12 with commit ce42ee423e58dffa5ec03524054c9d8bfd4f6237

Fixed in 7.0 with commit a664bf3d603dc3bdcf9ae47cc21e0daec706d7a5

本地提权意味着，任何获得普通用户权限的攻击者，都可以利用这个漏洞直接拿到服务器的root权限。对于云主机、容器环境和开发机来说，这等同于大门敞开。

"So this is one of the worst make-me-root vulnerabilities in the kernel in recent times."

—— Eddie Chapman

影响范围：这些版本正在裸奔

好消息是，主线版本已经修复。坏消息是，大量正在运行的长期支持版（LTS）内核还在危险区。

根据官方披露，修复仅存在于以下版本：6.18.22、6.19.12，以及即将到来的7.0。而以下长期支持版本尚未收到补丁：

6.12、6.6、6.1、5.15、5.10......

是的，你没看错。从企业服务器到嵌入式设备，从云厂商的宿主机到你的个人工作站，只要内核版本在受影响范围内且没有手动升级，都在射程之内。

"Longterm 6.12, 6.6, 6.1, 5.15, 5.10 have not received the fix and I don't see anything in the upstream stable queues yet as I write. My guess is backporting that far back is not as straightforward."

—— Eddie Chapman

更麻烦的是，Sam James在尝试回溯移植补丁时发现，由于这九年间内核API发生了多次变更，修复代码"does not apply cleanly"。简单说，就是没法直接打补丁，得针对旧版本重新写。

开发者震怒：为什么没人提前通知？

这次事件暴露了一个令人不安的流程漏洞：发行版没有提前收到预警。

Gentoo核心开发者Sam James在oss-security邮件列表中透露，直到公开披露前，他们对此毫不知情。

"Note that for Linux kernel vulnerabilities, unless the reporter chooses to bring it to the linux-distros ML, there is no heads-up to distributions. It did not happen here."

—— Sam James

这意味着什么？意味着当漏洞信息被公开时，各大发行版的维护者们和普通用户一样，也是第一次看到。没有缓冲期，没有预先准备的补丁，所有运行旧内核的生产环境都暴露在攻击者的探针之下。

Sam James还无奈地表示，他现在还得面对"AI slop"带来的额外负担。你看，连内核开发者都躲不过AI生成垃圾信息的骚扰，这日子真是没法过了。

临时救命方案：Gentoo团队的权宜之计

在官方补丁到位之前，Sam James提供了一个不是办法的办法：直接禁用authencesn模块。

虽然他不是IPSec专家，但认为这是"the lesser evil"（两害相权取其轻）。毕竟，断掉一部分加密网络功能，总比让攻击者拿到root权限要强。

如果你现在就想动手，可以参考社区给出的临时缓解思路。核心逻辑是阻止有问题的内核模块加载：

# 查看当前是否加载了authencesn模块
lsmod | grep authencesn

# 如果已加载，立即卸载（注意：可能影响IPSec相关服务）
sudo modprobe -r authencesn

# 临时阻止加载
echo "install authencesn /bin/false" | sudo tee -a /etc/modprobe.d/disable-authencesn.conf

需要强调的是，这只是权宜之计。如果你的生产环境重度依赖IPSec，禁用这个模块可能会带来副作用。但在补丁到位之前，这是少数能立刻降低风险的手段之一。

行动清单：接下来24小时你该做什么

别光顾着看热闹，这份清单请直接转发给你的运维同事：

1. 立刻自查内核版本
uname -r 看一眼，如果在4.14到未修复的LTS之间，进入警戒状态。

2. 检查authencesn模块状态
运行 lsmod | grep authencesn，如果返回结果不为空，你的风险等级正在飙升。

3. 评估升级可行性
如果业务允许，优先升级到6.18.22或6.19.12。如果不行，密切关注你所用发行版的安全公告。

4. 考虑临时禁用风险模块
在非IPSec核心系统上，可以参考上面的命令先行缓解。

5. 加强本地权限管控
在补丁到位前，严格控制普通用户登录和权限分配，别让攻击者有本地执行的机会。

写在最后

CopyFail给我们上了一堂残酷的安全课：在开源世界，一个9年前的代码提交，可以在今天掀起轩然大波。而面对这种级别的漏洞，没有收到预警的发行版维护者，和热锅上的蚂蚁没什么两样。

作为开发者，我们能做的就是保持警惕，及时跟进，千万别觉得"我的系统很稳定"就高枕无忧。毕竟，稳定和安全，从来都不是一回事。

你的服务器内核版本是多少？评论区报个数，看看多少人已经在危险区了。

#Linux内核安全 #CVE202631431 #CopyFail漏洞 #服务器运维 #开发者自救指南