CVE-2026-31431 (Copy Fail) - 我们如何缓解它

上周披露了一个严重的 Linux kernel 本地权限提升漏洞：CVE-2026-31431，昵称为 "Copy Fail"。它影响现代 Linux 发行版中的大量 kernel 版本，披露后很快就出现了公开 exploit。

我想坦诚说明发生了什么、这对 Appbox 意味着什么，以及我们做了什么。简短版：得益于我们构建 containers 的方式，在 patched kernels 推出之前，使用 user namespace remapping 运行的应用就已经能防止它演变为 host root。昨天（2026 年 5 月 4 日），我们也执行了紧急维护，将每台服务器升级到已修复的 kernel，因此该 bug 现在已从我们的 fleet 中完全消失。

什么是 "Copy Fail"？

CVE-2026-31431 是 kernel 的 AF_ALG cryptographic API 中的漏洞。通过绑定到特定 cipher（authencesn(hmac(sha256),cbc(aes))），并滥用 kernel 将 pages splice 到 scratch buffer 的方式，未授权本地用户可以把任意 4-byte chunks 直接写入 page cache 中原本无权修改的文件，包括 /usr/bin/su 这样的 SUID binaries。

一旦 su 的 page cache 副本被一个很小的恶意 ELF 覆盖，下次调用时就会以 UID 0 运行攻击者代码。对 host 来说就是 game over。

想看扎实的技术细节（shellcode disassembly、syscall traces 等），Andrea Veri 的文章非常出色：CVE-2026-31431: Copy Fail vs. rootless containers。他还通过 eBPF 和 uid_map 证明演示了我们接下来要讲的内容：user namespaces 会中和这个 exploit。

为什么 Appbox 应用已经得到缓解

该 exploit 依赖 setuid(0) 真正授予 host root。在启用 user namespaces 的 container 中，情况并非如此。

User namespaces 会把 container 的 UID 空间映射到 host 上另一个（非特权）UID 范围。因此，当 exploit 在 container 内成功且 setuid(0) 返回成功时，产生的 "root" shell 会被映射为普通非特权 host 用户，而不是真正 root。shellcode 会运行，提示符变成 #，但在 host 上：

podman     27943  0.0  0.0   2984  2028 pts/1    S+   22:15   0:00 sleep 100

就是这样。没有 host 文件访问，没有 /etc/shadow，没有 host root。container 的 namespace 边界阻止它变成 host-root escape。

在平台层面，每个 Appbox 都有自己的 Docker daemon，并启用了 user namespace remapping。用 pseudocode 表示，更像这样：

start_docker_daemon(
  userns_remap = appbox_id,
  container_namespace = appbox_id
)

该映射由 host 上专用的 subordinate UID/GID 范围支持：

write "/etc/subuid" -> "<appbox-id>:<host-subuid-start>:65536"
write "/etc/subgid" -> "<appbox-id>:<host-subgid-start>:65536"

除此之外，当某个应用需要特殊处理时，应用定义仍可以显式覆盖 UsernsMode：

container_config = {
  userns_mode: app.userns_mode,
  network_mode: app.network_mode,
  ...
}

所以准确的描述是：user namespace remapping 是平台默认设置的一部分，而每个应用的例外都是显式的。确实有少量应用因为暴露需要额外 capabilities 的功能而需要不同设置，这些情况会单独处理。

换句话说：对使用正常 remapped setup 运行的应用来说，Copy Fail 无法把 container compromise 变成 host root。

我们仍然想修复什么

User namespaces 阻止了 host escape，但它们不会让 container 内的 bug 消失。攻击者仍可能在应用边界内提升到 "container root"，虽然被限制住了，但这仍然不是好状态。kernel 本身有漏洞，我们希望把它彻底移除。

得知该 bug 后，我们立即开始评估暴露面。虽然 user namespace remapping 已经在我们的常规应用设置中阻止了问题的 host-escape 侧影响，但我们仍然希望尽快消除底层 kernel bug。

昨天我们做了什么

周日晚，我们为 2026 年 5 月 4 日星期一 安排了紧急维护，这是我们能在整个 fleet 上推出 kernel 升级的最早窗口。

维护窗口期间：

• 每台 host 都使用包含 "Copy Fail" 修复的官方 Debian kernel packages 完成升级。
• 目标很简单：完全移除易受攻击的 kernel path，而不是只依赖现有 namespace isolation。

维护已经完成。每台 Appbox host 现在都运行 patched kernel。

这对你意味着什么

• 你无需做任何事。你的应用继续运行，维护窗口内任何短暂波动都是唯一对客户可见的影响。
• 即便在昨天的 patch 之前，user namespace remapping 也意味着这个 bug 无法把正常应用 compromise 转变为 host root。这正是这种 isolation model 要处理的场景。
• 未来，我们的政策不变：user namespaces 默认开启，极少数例外会经过额外安全审查。

更大的图景

这是那种标题听起来很灾难性的 CVE（"local privilege escalation, public exploit, every modern kernel affected"），而对很多 shared-tenant environments 来说它确实很严重。它对我们不是灾难的原因，正是我们多年前做出某些架构决策的同一个原因：这些决策偶尔会牺牲一点兼容性，但我们把 least privilege 原则内置在 container 层，而不是事后补上。

Defence in depth 确实有效。Kernel 层有 bug？namespace 层挡住了。Namespace 层有 bug？capability drops 和 seccomp 能挡住其中大部分。我们不会假装任何单层都是完美的，只会确保后面总还有下一层。

如果你对此有任何问题，或想了解你的特定应用如何配置，请联系我们。

有问题？请通过 support@appbox.co 联系我们，或在 billing.appbox.co 提交工单。