Linux Kernel "Copy Fail" (CVE-2026-31431) 提权漏洞分析

技术
, ,

昨天刚给根分区清理完空间准备写博客，结果新闻推送就弹了一条：New Linux ‘Copy Fail’ Vulnerability Enables Root Access on Major Distributions.

好家伙，又来了。

Linux kernel 安全漏洞这些年早就见怪不怪了，但 “Copy Fail” 这个名字起的还挺有意思的——一看就是个跟 copy_from_user 有关的故事。

漏洞概况

  • CVE 编号: CVE-2026-31431
  • 漏洞名称: Copy Fail
  • 类型: Local Privilege Escalation（本地提权）
  • 影响范围: 几乎所有主流 Linux 发行版
  • CVSS 评分: 7.8（High）
  • 漏洞存在时间: 自 2017 年起，潜伏约 9 年
  • 利用难度: 已有公开 PoC，732 字节的 exploit，”reported to work reliably”

听起来挺严重的。作为一个每天都在跟 Linux 打交道的用户，我决定仔细看看这个漏洞到底是怎么回事。

漏洞原理

“Copy Fail” 的逻辑缺陷位于 Linux 内核的 pipe/splice 机制中，核心问题跟 copy_from_user() 的返回值处理有关。

简单来说，copy_from_user() 这个函数负责把用户空间的数据拷贝到内核空间。正常的调用方会在拷贝完成后检查返回值——如果返回值非零，说明拷贝没有完全成功，部分数据丢失了，这时候应该 abort 当前操作。

但是 Copy Fail 的问题在于：内核在处理 pipe 的某些路径时，对 copy_from_user 的失败返回值处理不当，导致了一种 TOCTOU（Time-of-Check-Time-of-Use） 类型的漏洞。攻击者可以利用这个逻辑缺口，通过精心构造的 splice 系统调用，往其他进程的文件页缓存（page cache）中写入数据，最终实现 root 提权。

这里的关键是并不是 copy_from_user 本身出了 bug，而是调用方对它的返回值做了一个错误的假设——认为拷贝要么全成功，要么全失败。但实际上，在一些边界情况下，内核的某些路径会看到”部分成功”的状态，而这个状态没有被正确处理。

这其实是内核安全里非常经典的一个模式：不是 API 错了，是你用错了。

影响范围

因为这个漏洞位于 pipe 机制中，而 pipe 是所有 Linux 发行版都有的基础 IPC 机制，所以影响范围非常广。几乎所有从 2017 年左右到现在的 Linux 内核版本都受影响。

各个发行版的修复状态：

发行版 状态
Arch Linux 已发布修复，linux / linux-zen / linux-lts 均已更新
Ubuntu 已提供修复，关注 linux 包的更新
Debian 修复中
RHEL / CentOS 已有补丁
SUSE 已修复

我这边的情况

检查一下我这台机器的内核版本：

1
2
3
4
5
❯ uname -r
7.0.3-zen1-1-zen

❯ pacman -Q linux-zen
linux-zen 7.0.3.zen1-1

然后看一眼补丁状态：

1
2
❯ zgrep -i "copy.fail\|CVE-2026-31431" /usr/lib/modules/$(uname -r)/config 2>/dev/null; echo $?
1

嗯，没有直接匹配到，不过这不代表有漏洞——因为补丁可能在之前的内核版本中已经合入了。直接查 Arch 的公告更靠谱。

根据 Arch Linux 的 security tracker，linux-zen 7.0.3.zen1-1 这个版本已经包含了修复。还好最近有勤快更新内核。

如果还没更新的，赶紧跑一下：

1
sudo pacman -Syu

对于不想重启的，可以考虑用 kexec 或者等下一次维护窗口。

一些看法

说实话，这类漏洞这些年见得太多了：一个 API 的错误使用方式，在内核里潜伏了将近十年才发现。

这其实反映了一个更深层的问题——copy_from_user 作为一个使用极其频繁的内核 API，它的语义虽然看起来很简单（”把数据从用户空间拷贝到内核空间”），但在不同的上下文下，开发者对它的行为预期经常会出现偏差。特别是在 pipe、splice、io_uring 这些相对较新的机制中，老的 API 被用在新的场景下，边界条件就容易出问题。

从防御的角度来说，这类漏洞没有太多花哨的缓解措施：

  1. 保持内核更新 —— 这是最有效的防护。Arch 这种滚动更新的发行版天然有优势。
  2. 最小权限原则 —— 如果你的机器不是多用户环境，本地提权的威胁模型相对较小。
  3. 关注安全公告 —— 订阅 Arch 的安全邮件列表或者关注 arch-security 的 RSS。

写在最后

Copy Fail 不是那种会让人晚上睡不着觉的漏洞——它需要本地访问权限，远程利用的威胁不大。但对于服务器环境或者多用户系统来说，还是应该尽快更新。

对我来说，这次最大的收获是又见识了一次内核安全领域的经典 bug 模式：底层 API 没错，上层的逻辑错了。这种 bug 往往最难发现，因为它不是”写错了”，而是”想错了”。

写这篇文章的时候我的 AI 助手（Pikka）帮我查了不少资料——包括抓取了 Tenable FAQ、SecurityWeek 等渠道的信息。作为一个跑在本机的 AI，它的确比我手动谷歌要快得多 😄