Linux Kernel on KnightLi的博客

Copy Fail 漏洞 CVE-2026-31431：Linux 内核文件复制路径中的容器逃逸风险

Fri, 01 May 2026 18:42:34 +0800

Copy Fail 是一个影响 Linux 内核文件复制路径的漏洞，编号为 CVE-2026-31431。 Bugcrowd 的分析把它称为一个值得关注的内核级问题：在特定条件下，非特权用户可以利用文件复制相关逻辑触发越权写入，进而造成权限提升或容器逃逸。

从风险角度看，它不是普通应用层漏洞。问题发生在内核处理文件复制和页面缓存的路径上，因此影响面会延伸到容器、共享主机、CI/CD Runner、PaaS 平台和多租户 Linux 环境。如果攻击者已经能在系统里运行低权限代码，漏洞就可能成为进一步突破隔离边界的跳板。

漏洞大致发生在哪里

Copy Fail 关联的是 Linux 内核中的文件复制能力。现代 Linux 提供了多种高效复制路径，例如 copy_file_range、splice 类路径以及不同文件系统之间的数据复制优化。这些机制的目标是减少用户态和内核态之间的数据搬运，提高大文件复制性能。

问题在于，高性能复制路径通常会复用页缓存、文件偏移、权限检查和文件系统回调。如果其中某个边界条件处理不严，内核可能在错误的权限上下文里执行写入，或者把本不应该被修改的数据页暴露给攻击者控制。

Copy Fail 的核心风险可以概括为：

攻击者不需要 root 权限；
攻击入口来自常见文件复制能力；
影响点在内核态；
在容器环境里，漏洞可能绕过命名空间和挂载隔离；
成功利用后可能写入宿主机上不应被容器修改的内容。

这也是它被重点讨论的原因。容器安全依赖 Linux 内核提供隔离能力，一旦内核路径本身出现越权写入，容器边界就会变得脆弱。

为什么容器场景更敏感

容器并不是虚拟机。容器内进程和宿主机共享同一个 Linux 内核，只是通过 namespace、cgroup、capability、seccomp、AppArmor/SELinux 等机制做隔离。

如果漏洞发生在用户态服务里，通常只影响某个容器或某个进程。但如果漏洞发生在内核里，尤其是可以被非特权用户触发的内核漏洞，攻击者可能从容器内部影响宿主机。

Copy Fail 的危险点就在这里。很多平台允许用户提交构建任务、运行脚本、启动容器或执行插件。攻击者只要能在容器里运行代码，就可能尝试利用内核文件复制路径突破隔离。

高风险环境包括：

Kubernetes 集群中的不可信工作负载；
CI/CD 平台的共享 Runner；
允许用户上传代码执行的沙箱平台；
多租户 Linux 主机；
容器化 PaaS；
运行第三方插件或扩展的系统。

如果这些环境里的内核版本处于受影响范围，而且缺少额外限制，风险就会明显升高。

受影响范围要看内核补丁状态

这类漏洞的判断不能只看发行版名称。同一个 Ubuntu、Debian、RHEL、Fedora 或 Arch 版本，是否受影响取决于当前实际运行的内核包，以及发行版是否已经回补补丁。

排查时应优先确认三件事：

当前运行内核版本；
发行版安全公告是否提到 CVE-2026-31431；
云厂商或托管平台是否已经完成宿主机内核修复。

可以先在系统上确认内核版本：

`1`	`uname -a`

然后查看发行版安全公告、内核 changelog 或云平台公告。不要只根据主版本号判断是否安全，因为很多企业发行版会把安全补丁回补到旧版本内核里。

临时缓解思路

最可靠的修复方式仍然是更新内核。但在补丁无法立刻部署的环境里，可以先降低暴露面。

常见缓解方向包括：

禁止不可信用户运行特权容器；
避免给容器挂载敏感宿主机路径；
收紧容器 capability，尤其不要随意授予 CAP_SYS_ADMIN；
使用 seccomp、AppArmor 或 SELinux 限制危险系统调用和文件访问；
将不可信工作负载迁移到隔离更强的虚拟机；
对 CI/CD Runner 做按任务销毁，避免长期复用同一宿主机；
监控异常文件写入、权限变更和容器逃逸迹象。

这些措施不能替代补丁。它们的作用是降低攻击成功率和影响面，特别是在补丁发布到生产环境之前争取缓冲时间。

修复优先级

建议按环境风险排序处理。

优先修复：

对外提供容器执行能力的平台；
运行不可信代码的 CI/CD 节点；
多租户 Kubernetes 节点；
有用户自定义插件或脚本执行能力的系统；
共享开发机、教学机、实验平台。

相对低优先级：

单用户桌面；
只运行可信服务的内网主机；
已经使用虚拟机隔离不可信代码的环境。

即便风险较低，也建议随发行版更新内核。内核漏洞常常会被组合进更复杂的攻击链里，拖延补丁没有太多收益。

给运维团队的检查清单

可以按下面顺序处理：

盘点所有 Linux 主机和容器节点；
标记会运行不可信代码的机器；
检查当前内核版本和发行版安全公告；
优先更新高风险节点；
对无法立即更新的节点启用临时隔离策略；
检查容器运行时配置，移除不必要的特权和宿主机挂载；
更新后重启节点，确认新内核已经实际生效；
保留变更记录，方便后续审计。

内核包安装完成并不代表系统已经运行在新内核上。更新后必须重启，并再次确认：

`1`	`uname -a`

小结

Copy Fail / CVE-2026-31431 的重点不是某个应用崩溃，而是 Linux 内核文件复制路径中的权限边界问题。它让非特权代码有机会触碰更高权限的数据写入路径，因此在容器和多租户环境里尤其值得重视。

处理这类漏洞时，最重要的是两件事：

尽快跟进发行版或云厂商提供的内核补丁；
在补丁部署前限制不可信代码、特权容器和敏感宿主机挂载。

对个人桌面来说，它可能不是马上需要恐慌的问题。但对运行容器平台、CI/CD、沙箱和共享主机的团队来说，应该把它当作高优先级内核安全更新处理。

参考来源：

Linux Kernel 7.0 更新特性整理

Fri, 01 May 2026 14:46:07 +0800

Linux 内核版本号一直不是语义化版本号，主版本号提升更多是维护节奏上的滚动。 Linus Torvalds 在发布邮件中也把 7.0 描述成一次正常发布：最后一周主要是网络、架构、工具、自测和驱动等方向的小修小补。

真正值得关注的是这批增量更新本身。 Linux 7.0 覆盖了文件系统、内存管理、硬件支持、安全隔离、Rust 支持和驱动清理等多个方向。

文件系统：XFS、EXT4、NTFS3 都有变化

Linux 7.0 最容易被感知的一类更新在文件系统。

XFS 引入了自修复相关能力。配合新的通用文件系统错误报告机制，文件系统可以把元数据损坏和 I/O 错误通过更统一的方式传递到用户空间。在合适的系统服务配合下，XFS 可以在文件系统仍然挂载时自动处理部分修复流程。这并不等于所有磁盘损坏都能无痛修好，但对服务器和长期运行系统来说，错误发现和修复链路更完整。

EXT4 继续改善并发 direct I/O 写入表现。如果机器上经常有备份、构建、下载、数据库或日志任务同时写盘，这类优化会让并发写入路径更稳。它不是那种所有桌面用户马上能感知的变化，但对高 I/O 场景有意义。

NTFS3 也获得了较大的驱动更新，包括 delayed allocation、基于 iomap 的文件操作，以及大目录扫描场景下更好的 readahead。如果经常在 Linux 下访问 Windows 分区或外接 NTFS 磁盘，这类更新更值得留意。

此外，exFAT 改进了多 cluster 顺序读取，部分小 cluster 设备在顺序读取时会更快。

内存与 swap：继续优化内存压力下的表现

Linux 7.0 延续了前几个版本对 swap 子系统的整理。这次重点之一是改进从 swap 读回内存的路径，尤其是多个进程共享同一批被换出的内存页时，吞吐会更好。

对桌面用户来说，这不一定会变成明显的“系统突然更快”。但在内存紧张、容器密集、Redis 这类服务启用持久化，或 zram 搭配后端磁盘的场景里，这类变化会减少系统在内存压力下的抖动。

zram 相关路径也有优化。过去某些情况下，内核需要先把 zram 页面解压再写入后端设备；新的路径可以直接写入压缩数据，减少不必要的处理。

CPU 与性能：Intel TSX auto、线程和文件操作更快

Linux 7.0 对 Intel TSX 的默认策略做了调整。过去因为安全问题，TSX 在不少处理器上默认关闭。现在内核采用更细的 auto 策略：受影响的 CPU 继续关闭，不受影响或适合启用的 CPU 可以自动打开。

这对部分多线程工作负载会有帮助，尤其是依赖事务同步扩展的应用。不过它不是通用加速开关，实际收益仍取决于 CPU 型号和应用是否使用相关能力。

另外，Linux 7.0 还包含 PID 分配、线程创建/销毁、文件 open/close 等路径的优化。这些优化通常不会单独成为宣传点，但会积累成系统响应和高并发服务上的细微收益。

硬件支持：新平台预备和现有设备改善

Linux 7.0 继续做大量硬件启用工作。这类更新通常分成两类：一类是还没大规模上市的新平台预备，另一类是已经在用户手上的设备改善。

新平台方面，Linux 7.0 包含更多 Intel Nova Lake、Intel Crescent Island、AMD 新图形 IP、AMD Zen 6 相关准备工作。这类改动对普通用户不一定马上有用，但它决定了新硬件上市后能否更快获得主线内核支持。

ARM64 和单板机方向，Rockchip RK3588/RK3576 的 H.264/H.265 硬件视频解码进入主线支持范围。这意味着 Orange Pi 5、Radxa ROCK 5 等设备不再完全依赖厂商 BSP 内核才能获得硬解体验。

笔记本和外设方向也有不少细节更新：

ASUS WMI 改善 ROG、TUF 机型的背光、键盘灯和风扇快捷键支持；
HP WMI 增加部分 Victus 机型的手动风扇控制和音频指示灯修正；
Lenovo WMI 为 Legion 设备暴露更多 HWMON 监控信息；
Intel Xe 图形驱动暴露更多温度传感器；
Intel Arc B 系列独显可以进入更深的 PCIe 省电状态；
Rock Band 4 蓝牙吉他和 Logitech K980 蓝牙键盘获得更好的内核支持。

这些变化单看都不大，但对笔记本、游戏设备、开发板和外设用户来说，主线内核支持越完整，后续发行版维护越省心。

安全与隔离：io_uring 可以做 BPF 过滤

Linux 7.0 给 io_uring 增加了 BPF 过滤能力。这对容器、沙箱和高安全要求环境比较重要。

过去一些管理员为了降低攻击面，会直接禁用 io_uring。现在通过 BPF 过滤，可以更细地限制允许的操作，而不是只能在“全开”和“全关”之间选择。

这不会让 io_uring 的安全风险自动消失，但给系统管理员和运行时框架提供了更可控的隔离手段。

Rust 支持不再只是实验标签

Linux 7.0 中，Rust for Linux 的状态进一步稳定。这不意味着内核会大规模改写成 Rust，也不意味着 C 会被替代。

更准确地说，Rust 在内核里的基础设施已经进入更正式的阶段。后续新驱动、新子系统或部分安全敏感代码，可以在合适场景下选择 Rust。这是一条渐进路线：先把接口、构建、文档和维护流程打稳，再让具体代码慢慢增加。

清理旧功能：laptop_mode 被移除

Linux 7.0 移除了 laptop_mode。这是一个历史很久的省电功能，主要面向机械硬盘时代的笔记本，通过减少磁盘唤醒来节省电量。

现在笔记本主流已经是 SSD，内核里的内存回收、块设备和文件系统路径也发生了很多变化。继续保留这种老机制会增加维护成本，而且测试覆盖并不理想。移除它可以减少旧代码对现代路径的干扰。

AI 相关按键：面向新一代键盘交互

Linux 7.0 增加了几个新的 HID keycode，用于上下文 AI 交互场景，例如对选中内容执行动作、插入上下文生成内容、发起上下文查询等。

这并不是内核内置 AI 功能。它更像是给未来笔记本键盘和外设留好输入事件定义，让桌面环境、应用或厂商工具可以识别这些按键。实际能做什么，仍取决于发行版、桌面环境和应用层集成。

是否应该马上升级

如果你使用滚动发行版，Linux 7.0 很可能会自然进入系统更新。如果你使用 Ubuntu 26.04 LTS 这类新发行版，7.0 也会作为默认或主要内核版本出现。

但如果你的机器是生产环境、NAS、虚拟化宿主机，或依赖闭源驱动和专有内核模块，不建议只因为版本号变成 7.0 就立刻手动升级。更稳妥的做法是：

等发行版提供正式内核包；
查看显卡、网卡、ZFS、VirtualBox、VMware、DKMS 模块兼容性；
在测试机或快照环境里先验证；
关注 7.0.x 小版本修复情况。

截至 kernel.org v7.x 目录，7.0.1、7.0.2、7.0.3 已经陆续发布。如果要手动构建或测试，优先选择最新的 7.0.x 稳定小版本，而不是只盯着最初的 7.0 tarball。

小结

Linux Kernel 7.0 不是一次“因为大版本号而重写一切”的发布。它更像是一次覆盖面很广的常规内核更新：文件系统更可靠，swap 和 I/O 路径继续优化，新硬件支持继续前移，Rust、io_uring 隔离和 HID 输入定义也在补齐长期演进所需的基础设施。

对普通桌面用户来说，最实际的变化可能来自硬件支持、图形驱动、省电和文件系统修复。对服务器和开发者来说，XFS 错误报告、自修复、io_uring BPF 过滤、swap 优化和新平台支持更值得关注。

参考来源：