UEFI 固件 EDK2 的 PXE 驱动藏了 16 年的缓冲区溢出（CVE-2026-97631，CVSS 4.0 9.5 分）：PXE 启动窗口内可抢在操作系统前执行代码
TianoCore EDK2 10 月 22 日公告 CVE-2026-97631：PXE 启动时一封超大 ICMP 错误即可在系统前执行代码，暂无修复版本。
TianoCore EDK II（EDK2）是绝大多数 UEFI 固件的代码底座，AMI、Insyde、Phoenix 三家主流 BIOS 厂商和微软的 Project Mu 都基于它构建；它的 PXE 网络启动驱动 NetworkPkg/UefiPxeBcDxe 里有一个被 Ars Technica 称为「16 年老洞」的缓冲区溢出，2026 年 10 月 22 日以 CVE-2026-97631 公开，上游按 CVSS 4.0 打了 9.5 分。漏洞的触发条件写在公告里：机器正在 PXE 启动（IPv4 或 IPv6），攻击者能向它投递一封超大 ICMP 错误报文——504 字节的固定字段被越界写入，代码就能在操作系统加载、Secure Boot 与 TPM 校验生效之前跑起来。同一份公告同时写明：截至发布「没有已修补的版本」（Not patched currently），修复 PR 已于 10 月 15 日合入 master，但只更新固件才能吃到。
要点
- 触发窗口极窄但代价极高：只在 PXE 网络启动进行期间可打，一封超过 504 字节的 ICMP 错误报文即可在 DXE 阶段写坏内存，公告列出的后果是启动挂死（拒绝服务）或在 ring 0 执行攻击者字节。
- 防线在它身后：代码执行发生在 Secure Boot 验证、TPM 度量任何 OS 组件之前，Eclypsium 的 Jesse Michael 指出与 BootHole、BlackLotus 不同，这个洞修复只需代码补丁，不用吊销 Secure Boot 密钥或更新 dbx。
- 评分出现分歧：上游与 NVD 按 CVSS 4.0（AV:N 网络可达、攻击条件 AT:P）给 9.5，Red Hat 按 CVSS 3.1（AV:A 相邻网络）自评 8.8——两套体系对攻击距离的假设不同。
漏洞机制
UefiPxeBcDxe 在网络启动时保持一个针对 ICMP 错误报文的接收请求，每收到一封就把内容拷进私有上下文结构里 504 字节定长的 Mode.IcmpError 字段。公告写明两处缺陷同时存在：拷贝循环的边界检查不正确，超过 504 字节仍然继续拷；目的指针按「累计分片长度」而不是「单片长度」推进，IPv4（PxeBcIcmpErrorDpcHandle）和 IPv6（PxeBcIcmp6ErrorDpcHandle）两条路径都中招，接收路径上游也没有任何长度限制兜底。
后果分两档。最轻的一档是确定性的：驱动私有数据被写坏，下一个 ICMP 错误触发 DXE 核心里的 CPU 异常，启动挂死——对靠 PXE 批量装机或恢复的机房，这就是拒绝服务。第二档才是真正的要害：熟悉目标固件构造的攻击者可以在同一个包里伪造事件，让 DXE 阶段的 CoreSignalEvent() 把攻击者提供的字节当代码执行，此时操作系统尚未加载，任何 OS 层安全控制都不存在。
攻击面听起来吓人，门槛其实落在两个词上：窗口与定制。曝光窗口只有 PXE 启动本身持续的这段时间，攻击者只要能把单播 ICMP 错误报文送达目标 IP 即可——公告原文写明「不限网络距离」（from any network distance）；Ars 的判断更保守一些，认为需要先控制目标所在的本地网络。Eclypsium 首席研究员 Jesse Michael 说，攻击者「需要猜测目标系统内的特定地址」，利用载荷要按目标固件的型号、版本、配置逐一定制。Ars Technica 的读者讨论里还有人补充：前端负载均衡（文中举了 Cloudflare）常常挡住 ICMP 送达，能把风险再削一层。
谁受影响
EDK2 的地位决定了波及面：AMI、Insyde、Phoenix 这些给绝大多数服务器主板写 BIOS 的厂商，以及微软安全加固分支 Project Mu，都从 EDK2 派生代码，Ars 的标题直接说它「威胁地球上的大多数服务器」。MITRE 记录的影响范围是版本 0 至 edk2-stable202608——2026 年 8 月的稳定标签也还在清单上。Intel 回应称其安全支持期内的商业产品暂无已知受影响案例，但 OEM 仍可能自行集成 EDK2 代码；Arm 表示该 CVE「不直接适用于 Arm 产品组合」。两家公司的参考固件都大量借用 EDK2，AMD、Phoenix、AMI、微软、亚马逊则没有回应 Ars 的置证请求。
对家用来讲可以松半口气：只有开着 PXE 网络启动（机房装机常规配置）的机器暴露，只从本地磁盘启动的台式机、笔记本不在射程内；也没有证据表明它能作为互联网上的初始入侵入口。真正的暴露人群是数据中心运维、批量装机环境和固件供应链。
披露风波与修复
这次披露本身也是新闻。Ars Technica 的报道还原了时间线：发现者是 Anthropic 的 Alex Matrosov 与 Google 的 Dan Holmes，原定 1 月的协调披露（Ars 未写年份；按 AMI 相关 PR 9 月底已公开推算，应是 2027 年 1 月），被 AMI 上月提前发布的一个带代码修复的 pull request 打破，细节就此曝光；发现者注意到之后，TianoCore 成员才在 10 月 22 日发布公开公告。公告把「找到问题并提供推荐修复」一并致谢给 Matrosov（Anthropic）与 Dan Holmes-Mitra（Google，Ars 写作 Dan Holmes），而实际合入的 PR #13302 由 TianoCore 维护者 Michael D Kinney 在 10 月 14 日开启、10 月 15 日合入 master，提交记录里还保留了原始作者的改动；做法是加上边界检查、超长报文截断。PR 评论区里，10 月 27 日有人写明「embargo 因失误被违反，PR 因此在公开状态下创建」。GHSA 至今仍标着「没有已修补版本」，因为正式发布版里还没有这个修复。
Red Hat 已在自家 CVE 页给产品环境打出 8.8 分（CVSS 3.1，AV:A），比上游的 9.5 低 0.7 分。分歧不在事实而在度量：CVSS 4.0 的 AV:N 描述「网络可达」，但用攻击条件（AT:P）反映了「要赶上 PXE 窗口」这类现实约束；CVSS 3.1 没有这个维度，Red Hat 直接按相邻网络给分。读报告时两边都要看，别只挑大的那个数。
| 项目 | 状态（2026-10-22 公告时） | 出处 |
|---|---|---|
| CVE 编号 | CVE-2026-97631 | MITRE/NVD |
| 上游评分 | CVSS 4.0 9.5（AV:N/AT:P） | GHSA |
| Red Hat 评分 | CVSS 3.1 8.8（AV:A） | Red Hat |
| 影响版本 | 至 edk2-stable202608 | MITRE |
| 已修复版本 | 无（master 已合入，发行版待跟进） | GHSA |
| 修复 PR | #13302，10-14 创建、10-15 合入 master | GitHub |
| 发现者 | Alex Matrosov（Anthropic）、Dan Holmes（Google） | Ars |
运维怎么办
对管着服务器的人，这份公告换来的动作清单很具体。第一步是盘点：哪些机型走 PXE 装机或网络恢复、BIOS 来自哪家、版本是否包含合入补丁——正式固件发布前，master 上的修复对现网机器是够不着的。第二步是压缩窗口：在固件更新可用前，把常规运行机器的 PXE 网络启动关掉，只在装机网段保留；EFI 开发者可以先在自己的构建里带上 #13302。Ars 引导的通用建议还包括照常启用 Secure Boot 与 TPM（它们挡不住这个洞，但仍挡着其他攻击），以及盯紧启动相关日志。这个洞最麻烦的归宿是 HD Moore 说的那种：Metasploit 作者、Dragos CRO 评价它能「在启动过程仍可访问 TPM 等敏感组件的时点劫持程序流」，磁盘加密在失窃场景可能被绕开，而且作为「forever bug」长期活在停止支持的老机器里——固件更新到不了的地方，这个洞就一直在。
这个月的固件供应链不太平。我们本周写过 CISA 把遭在野利用的 PHP2Shell RCE 漏洞列入已知被利用目录，也写过 微软 Authenticator 零权限漏洞技术细节公开。和那两条不同，EDK2 这个洞卡在最难补的一层：应用漏洞等包更新，固件漏洞等 BIOS 发布，中间隔的是整机厂商的发版周期。