CVE-2026-13934

这是工作项目仓库。调查·分析·工作·报告都在一个仓库中处理(D088/D091)。

此文件是仓库·看板入口文档。文件夹·产出物规范的全文请参阅 docs/conventions.md。 正文(现状·结论·链接)在**报告(report)**条目晋升时更新。 调查·分析·工作代理不会修改根 README。

一句话摘要: Google Chrome 的 WebGPU 实现 Dawn 在创建 YCbCr 采样器时未检查 Vulkan 规范所要求的参数约束,导致已掌握渲染器进程的攻击者可将违反规范的值一路传送到 GPU 进程(CWE-20)。修复以两层方式加入验证与后端强制,并已在 Chrome 150.0.7871.47 中生效。

详细学习文档位于 docs/cve-2026-13934/ — 已按无需复现即可跟进原因·修复·实证·教训的方式编写。

现状

对象: CVE-2026-13934 — Google Chrome / Dawn (WebGPU 实现),漏洞类型 CWE-20 (Improper Input Validation)。CVE 发布于 2026-06-30,修复版本 150.0.7871.47。依据: research/20260804-cve-2026-13934-6bacf7/sources.md §1·§2。

进度阶段 — 按调查(公开信息) · 调查(补丁·diff) · 分析(复现·实证) · 报告(学习整理)四条线路推进,四条线路均已完成。

已确认事项

• CVE 标识符·状态(公开), CNA(Chrome/Google), 受影响产品(Google Chrome), 受影响组件(Dawn)。
• 修复版本 150.0.7871.47 与修复提交(Dawn 43055cbe…),变更的 3 个文件及变更原因。
• 易受攻击一侧的版本中没有任何规范约束检查·强制·回归测试,而修复一侧全部存在 — 已通过对 Chrome 实际固定的两个 Dawn 快照进行静态比对确认 (cases/20260804-cve-2026-13934-4d10a8/report.md §3)。

尚未确认事项 (未用推测填补)

• 无执行层面观察 — 未构建两个版本并运行单元测试。验证错误消息的实际输出、生成的 VkSampler 参数、Vulkan 验证层的 VUID 报告均为基于代码依据的预期值(cases/…-4d10a8/report.md §4)。
• 受影响平台 — CVE 描述为 "on Android",但收录该 CVE 的供应商公告是桌面渠道公告。未确认桌面端是否也成立相同路径。
• 受影响版本边界 — Chromium 标签 150.0.7871.46·.47·.63 均固定到同一个 Dawn 版本,但 CVE 写为 "prior to .47"。未能确认这一表述的依据。
• 修复的完整性 — Dawn 侧引用该 bug 的提交有 1 个,但未全面调查 Chromium src 侧是否有伴随变更。
• 供应商内部分析 — 包含根因的 Chromium issue 513006636 仍处于访问受限状态。

严重性 — 各来源不同。供应商(Chromium)自身评级为 Medium,CISA-ADP 的 CVSS v3.1 为 9.6 CRITICAL(CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:C/C:H/I:H/A:H),且 NVD 自身没有评估。 不判定哪一方正确,而是并列记录 — 解读详见 docs/cve-2026-13934/overview.md。

此仓库中没有部署的服务(API·后端·数据库等)。所有产出物均为文档。

主要结论

1. 原因 — 未检查规范所要求的前提

Vulkan 规范要求带有 YCbCr 变换的采样器所有轴的地址模式均为 CLAMP_TO_EDGE 且 各向异性过滤(anisotropy)处于禁用状态 (VUID-VkSamplerCreateInfo-addressModeU-01646)。补丁之前的 Dawn 未检查此约束, 因此违反规范的参数可以通过验证并一直到达 VkSampler 的创建。

关键在于威胁模型。公开描述以攻击者已掌控渲染器进程为前提 ("a remote attacker who had compromised the renderer process")。在该位置上,攻击者可以 直接操纵进程间命令而非正常 Web API 路径,因此渲染器侧的验证位于信任边界之外。 而 Dawn 的 Vulkan 后端运行在比渲染器权限更高的 GPU 进程中 — 因此该缺陷成为沙箱逃逸的攻击面。

依据: cases/20260804-cve-2026-13934-4d10a8/root_cause.md §2 · 详情: docs/cve-2026-13934/root-cause-and-fix.md

2. 修复 — 没有只做一层验证就结束

修复提交为 Dawn 43055cbeadddca41a9c973a809f859d641077b2f ("Add YCbCr sampler validation", 2026-05-27, Bug: 513006636),变更了三个文件。

这个结构正是本 CVE 的核心。 由于前提是渲染器已被攻破,仅靠验证不够, 在权限更高的一侧强制值的第二层才是实际的阻断线。如果概括为"因为缺少输入验证所以补充了验证", 就会错过防御设计的要点。

变更规模为新增 53 行,删除 0 行 — 这是不改动现有逻辑、只补齐缺失检查的补丁。

依据: research/20260804-cve-2026-13934-diff-92f928/report.md §3·§4 · cases/20260804-cve-2026-13934-4d10a8/patch_diff.md §4

3. 实证 — 已确认到静态层面

比对了 Chrome 实际固定的两个 Dawn 快照的源码。

此处揭示的事实: 易受攻击一侧原本就存在 YCbCr 分支和 2 处检查。缺陷不是路径缺失, 而是分支内的条件性约束检查缺失。

由于未进行构建·运行,下面两项是基于代码依据的预期,而非实测。

依据: cases/20260804-cve-2026-13934-4d10a8/report.md §1~§4 · 详情: docs/cve-2026-13934/evidence.md

4. 教训

安全设计角度

• 跨越信任边界的值必须在跨越后的一侧重新处理。 客户端·渲染器侧的验证是为了便利和诊断, 而在权限边界内侧应对值进行验证或强制。
• "规范要求的前提"如果不通过代码强制,就不会得到遵守。 条件性约束应在该条件成立的分支中 处理,而在本案例中,分支存在,只是缺少检查。
• 拒绝(reject)与修正(clamp)的角色不同。 本补丁在正常路径上拒绝,对来自信任边界之外的值 应用修正。
• 不要只凭一个严重性评级做判断。 同一漏洞同时存在供应商评级 Medium 与 CVSS 9.6 CRITICAL。 必须连同前提(渲染器被先行攻破)一起解读,才能看清实际风险。
• 不要把检测信号的方向颠倒。 验证错误消息仅在补丁之后才会产生。 "日志里没有该错误,所以是安全的"这一推论是反过来的。

调查方法角度

• 即使 CVE 参考链接中没有补丁,也可以追踪。 通过供应商公告中的 bug 编号 → 发布比对标签 → DEPS 中的组件版本 → 在组件提交日志中搜索 bug 编号,找到了修复提交。步骤: research/20260804-cve-2026-13934-diff-92f928/sources.md §6。
• 回归测试是最佳的观察规格。 补丁附带的测试定义了"什么输入产生什么结果", 因此无需危险的复现即可确认前后差异。
• 不把已确认与推测混在一起。 本仓库的产出物不会将未确认项留空,而是以"未确认 + 原因"的形式保留。

详情: docs/cve-2026-13934/lessons.md

产出物

学习文档 (docs/)

调查 — 公开信息·影响范围 (research/20260804-cve-2026-13934-6bacf7/)

调查 — 补丁·diff 比对 (research/20260804-cve-2026-13934-diff-92f928/)

分析 — 复现·实证(学习用) (cases/20260804-cve-2026-13934-4d10a8/)

报告 (reports/20260804-cve-2026-13934-8400bc/)

外部第一手来源 (要点)

• CVE Record: https://www.cve.org/CVERecord?id=CVE-2026-13934
• NVD: https://nvd.nist.gov/vuln/detail/CVE-2026-13934
• 供应商公告: Chrome Releases "Stable Channel Update for Desktop" (2026-06-30)
• 修复提交: https://dawn.googlesource.com/dawn/+/43055cbeadddca41a9c973a809f859d641077b2f

完整列表及发布日期·标识符位于两条调查线路的 sources.md 中。

定期收集: research/topics/<topic>/

规则 (摘要)

• 只提交文本。禁止二进制·转储·截图。单个文件 ≤ 1 MiB。
• 允许的路径: research/ · cases/ · work/ · reports/ · docs/ · .laurelin/ · .github/
• 人不直接提交,而是在 Laurelin 工作项目中下达指示 → 由 Aulë 提交。
• 详细规范: docs/conventions.md