containerd 2.4.2 补丁说明：三个 CVE、修复版本矩阵与升级后必须手工清理的 checkpoint 挂载
containerd 2.4.2 于 2026-10-13 发布，是 2.4 分支的第二个 patch 版本，含安全修补。同一批修复同时进入 2.3.7、2.2.10 和 2.0.14。
修复版本矩阵
| 编号 | 受影响区间 | 修复版本 |
|---|---|---|
| CVE-2026-95839 / GHSA-vwhp-8p66-mq4f | >=2.2.0,=2.3.0,=2.4.0,=2.0.0,=2.2.0,=2.3.0,=2.4.0,<2.4.2 | 2.0.14、2.2.10、2.3.7、2.4.2 |
| GHSA-8647-2jxj-p2rc | 与上一行同一批 patch 版本修复 | 2.4.2 等本批版本 |
| GHSA-5p7c-hggf-c748 | 走 CRI checkpoint restore 的 2.3 / 2.2 | 2.3.7、2.2.10 |
CVE-2026-95839：manifest 畸形 digest 导致 daemon panic
containerd 处理镜像 manifest 时，如果子 descriptor 带有 io.containerd.manifest.subject 注解且 digest 格式畸形，会触发未恢复的 panic。走 transfer service 拉取或导入镜像都会命中，包括默认的 CRI PullImage 请求。
Kubernetes 里 kubelet 对失败的镜像拉取带 backoff 重试，所以一个引用不可信镜像的 Pod 就能反复把 worker 节点上的 containerd 打崩。缓解手段只能是限制 Pod 引用可信仓库，真正的修复是升级到 2.2.10 / 2.3.7 / 2.4.2。
GHSA-hc94-p972-ch66：层数据先落盘、后校验 size
拉取镜像时，containerd 在把层数据写入 content store 之前没有校验传入字节数与声明 size 是否一致。用一个构造过的镜像，或从恶意 registry 拉取，就可以持续往宿主机磁盘写数据直到写满。在 Kubernetes 上表现为 node disk pressure，kubelet 与 containerd 无响应，新 Pod 起不来。
这条覆盖四条分支，2.0 线用户只有这一个问题，升到 2.0.14 即可。
GHSA-8647-2jxj-p2rc：伪造 Content-Length 打崩并行取层
恶意 registry 返回伪造的 Content-Length 头，在开启 concurrent_layer_fetch_buffer 并行取层时能让 containerd 崩溃。没有开启该项不影响触发路径，但仍建议随本批一起升级。
GHSA-5p7c-hggf-c748：checkpoint restore 失败泄漏 mount 与 pinned snapshot
CRI 插件在从 checkpoint 镜像恢复容器失败时，会泄漏只读 mount 和 pinned snapshot。反复用畸形 metadata、或拉不到 base image 的 checkpoint 镜像创建容器，可以逐渐耗光宿主机 mount 表和磁盘。
修复在 2.3.7 / 2.2.10。升级本身不会回收已经泄漏的资源，需要管理员手工处理：卸载宿主机上残留的 /tmp/checkpoint* 挂载点（或直接重启节点），containerd 才能回收那些 pinned snapshot。
# 找出残留挂载点
findmnt -rno TARGET | grep '^/tmp/checkpoint'
# 逐个卸载，卸载后 pinned snapshot 才可回收
umount /tmp/checkpoint
containerd 2.4 不支持通过 CRI 做 restore，因此不受该 bug 影响。
在 2.3 / 2.2 上如果暂时不能升级，可以关掉相关开关：
# config version 3
[plugins."io.containerd.cri.v1.runtime"]
enable_criu = false
enable_experimental_restore_via_create = false
# config version 2
[plugins."io.containerd.grpc.v1.cri"]
enable_criu = false
enable_experimental_restore_via_create 自 2.3.4 / 2.2.7 起默认就是 false，仍建议显式确认。
同批 hardening 带来的行为变化
- CRI 不再跟随容器日志文件的符号链接；
- 镜像分发拒绝含
..路径组件的镜像引用； - 默认 seccomp profile 对 socket 域做 allowlist。
这三项会改变既有行为，升级后要回归验证依赖软链日志的采集组件、以及自带 seccomp profile 的工作负载。
Docker Engine 用户
Docker Engine 29.9.1（2026-10-14）把静态 containerd 二进制更新到 v2.4.2，用 Docker 的机器打这个补丁即可覆盖上述 CVE。
Docker 29.9.2（2026-10-20）另有改动：Go runtime 更新后会拒绝包含 8 张被吊销 eMudhra 中间证书的证书链。registry 证书链依赖这些中间证书时，pull / push 会 TLS 校验失败——遇到这种情况要换证书链，而不是回退版本。
先升哪个
- CVE-2026-95839 优先。攻击面是默认的 CRI
PullImage，任何能创建 Pod 引用的镜像都可能是入口，且 kubelet 重试会放大成节点级故障。对外提供多租户、允许拉公共镜像的 worker 节点排在最前。 - GHSA-hc94-p972-ch66 次之。同样是拉镜像路径，后果是节点磁盘写满、进入 NotReady。
- GHSA-5p7c-hggf-c748 只涉及 2.2 / 2.3。已在 2.4 的集群升到 2.4.2 即可，不必单独处理；仍在 2.3 / 2.2 的，升到 2.3.7 / 2.2.10 并安排清理残留挂载。
- 分支对应关系：2.4.x → 2.4.2，2.3.x → 2.3.7，2.2.x → 2.2.10，2.0.x → 2.0.14。
升级后要手工确认什么
containerd --version与crictl info显示的目标版本是否落到修复版本；用 Docker 的机器查docker info里的 containerd 版本是否为 v2.4.2。/tmp/checkpoint*是否有残留挂载点。有则手工umount，否则 pinned snapshot 不回收，磁盘不会释放；确认后再看df与 snapshot 列表是否回落。- 2.3 / 2.2 节点上
enable_criu、enable_experimental_restore_via_create的实际取值。 - 行为变化项：容器日志软链、含
..的镜像引用、seccomp socket 域 allowlist 是否影响现有工作负载。 - 若 registry 证书链含被吊销的 eMudhra 中间证书，Docker 29.9.2 起会直接 TLS 失败，需替换证书链。