Chromium AV1 解码上下文未随序列重建（CVE-2026-15114）

1 第二段 720p 序列到了，柜子却没有长大

1.1 相同可见格式带来了另一份内部契约

故事从一次看似普通的切换开始。硬件解码器已经接收第一段编码视频序列，平台上下文创建完毕，一幅 1280×720 画面顺利显示。紧接着，同一数据流送来第二个序列头：配置档仍为 0，样本仍是 8 位，色度仍为 4:2:0，最大帧矩形连一个像素都没有移动。只看应用拿到的输出说明，旧资源似乎完全可以继续使用。

硬件上下文更像开工前一次配齐的工具柜。后端在创建阶段决定参考表面、概率状态、运动矢量存储、环路滤波临时区、中间画面与命令缓冲的数量和布局。某项能力没有在序列头中启用，驱动便可能省掉对应抽屉，或只给它留出较小空间。这种做法节省昂贵的 GPU 内存，也符合固定功能硬件对对齐和布局的严格要求。

第二个序列头没有要求更大的画布，却可能让柜后面的工人拿起一批原方案里没有的工具。顺序提示让时间关系生效，参考帧运动矢量让历史运动状态参与预测，联合复合与遮罩复合增加预测组合，超分辨率、CDEF 和环路恢复又带来新的处理阶段。应用依旧称它为 720p，硬件内部的工作清单却已经换了一张。

AV1 在每段编码视频序列前用序列头声明能力，后续帧头再在允许范围内选择具体操作。libgav1 把比特位解析为 ObuSequenceHeader，结构本身可以完全符合规范，但其中数值仍由不可信媒体控制。解析成功之后，Chromium 还必须回答一个寿命问题：旧结构创建的平台对象，是否能安全承接由新结构支配的帧。

这里存在两套相互关联却不能混为一谈的配置。显示配置回答消费者最后看到什么，包括尺寸、可见矩形、色彩空间、位深和采样。资源配置回答解码器为了产出这些像素，内部必须准备什么。两者有交集，却彼此都不完整包含另一方。用输出相等推导上下文兼容，会把两个状态机硬压成一个。

7 月修复的提交说明把缺失条件讲得很具体：流中序列头能够在常规配置不变时切换编码工具；Chromium 可能继续复用原硬件上下文和内存池；若新路径需要的临时工作区在旧上下文创建时没有分配，驱动状态会失去同步，随后可能越界读写。这条说明把语法、对象寿命和硬件内存后果接到了一起。可见输出越稳定，普通播放器和监控界面越难察觉变化；真正需要切换的是 GPU 进程里的上下文代际。

1.2 解析器认出了新序列，重置判断却少看了十一项

解析器没有错过第二个序列头。sequence_header_changed() 已经向 AV1Decoder::DecodeInternal() 报告编码视频序列发生变化，Chromium 也成功验证新头并重新计算输出字段。危险发生在识别之后：代码提出了一个不完整的兼容性问题，因此得到的假值只代表四个字段相等，却被当成整个硬件契约没有变化。

旧版 RequiresHardwareContextReset() 比较的四项都很合理。128×128 超级块会影响块级组织，胶片颗粒可能要求合成状态，CDEF 与环路恢复会带来各自的处理资源。它们的存在说明维护者早已知道，稳定的输出格式可能藏着不兼容的上下文。漏洞并非缺少重置概念，而是那份资源清单在第四项就结束了。

另有十一项开关没有进入结论。只要常规格式与原有四项保持相等，structural_change 便为假。解码器会安装新序列头并清空参考帧，却不会向拥有平台对象的上层发出配置变化。清空逻辑引用无法凭空生成缺少的临时表面，也无法重排创建时已经固定的驱动内存池。

这种漏洞很容易躲在看起来成熟的代码里：辅助函数名称准确，调用位置清楚，安全恢复路径也已经存在。缺口只在谓词内部列举的字段。共享解码代码的维护者看到重置函数，容易认为寿命问题已覆盖；各硬件后端又分别知道更多字段会影响创建资源。安全性要求把这些分散事实汇总到同一个公共关口。

多数日常视频不会把遗漏清晰暴露出来。有些流只出现一个序列头，有些在整个播放过程中维持同一工具集合，还有些切换工具的同时改变尺寸。尺寸变化本身就会触发 kConfigChange，等于替不完整的结构比较遮住了问题。最有辨识力的输入必须固定旧条件，只移动未列出的开关。

因此，问题发生在两次各自成功的操作之间。解析新语法成功，旧上下文解码第一段序列也成功；把两者组合才产生无效状态。新头带着第二段序列的许可，旧上下文仍保留第一段序列的分配假设。驱动接口的类型无法表达这个对象已经过期，只能依赖 Chromium 的布尔判断把时序义务传出去。关键时间窗位于新序列被识别之后、第一张新帧提交之前，配置事件、旧对象退出和新对象创建都必须在这里完成。

持久审计不能只盯着辅助函数本身。应从通用层和平台层反向追踪：创建 AV1 会话、表面池、固件参数块或持久参考资源时，究竟读取了哪些序列字段；每个值影响哪项创建决定；现有上下文由哪条比较失效。把这份独立清单与辅助函数做集合对照，才能发现函数内部肉眼审阅容易漏掉的成员。

清单还要标注字段寿命。有些语法只服务一帧，有些贯穿整段编码视频序列，还有些直接决定平台会话。若 API 允许，纯逐帧参数可以在固定会话中变化；用于尺寸、格式或配置持久状态的值，则必须在序列转换时结束旧对象。此次缺陷正是十一项后者没有进入共享寿命判断。

覆盖测试可以从寿命分类自动派生：固定全部公开格式判断，只移动一项对上下文敏感的值，并要求下一次提交前代际改变。AV1 依赖若不允许单项合法变化，就使用最小合法组合，同时断言每个解析成员。这样，后端知识会变成可执行清单，未来新增创建依赖也有明确测试入口。

解析器拒绝坏头属于另一种安全性质。一个畸形序列头在加速器之前失败，只能证明语法校验；它无法证明合法序列变化会重建持久资源。真正的安全回归测试必须足够符合规范并穿过正常解码，因为危险组合本来就是“合法新头加上只在上一个时间点合法的旧对象”。

2 解析器与加速器之间站着一道重置判断

代码定位与处置可以先压缩成一条线：固定提交 48c725cd3ed1 的 media/gpu/av1_decoder.cc 补全 RequiresHardwareContextReset()，AV1Decoder::DecodeInternal() 在新帧提交前把结果送入 kConfigChange 分支；回归位于同一提交的 media/gpu/av1_decoder_unittest.cc。Chrome 的固定版本是 Windows/macOS 150.0.7871.115 或 150.0.7871.114，以及 Linux 150.0.7871.114。永久处置是更新并彻底重启承载解码的进程；暂时无法更新时，可限时关闭 AV1 硬件解码，但必须在真实应用、子进程和嵌入视图中确认已经走软件路径。

2.1 DecodeInternal() 组装序列变化结论

沿调用路径向下走，重置动作并不神秘。AV1Decoder::SetStream() 接收解码缓冲区，并在其上创建 libgav1 的 ObuParser。若 Chromium 已经保存序列头，还会把这份状态交回解析器，使跨缓冲分段的帧继续解读。随后 Decode() 进入 DecodeInternal()，把时序单元、序列头、帧头、分块和输出决定排进同一段有序事务。

当 parser_->sequence_header_changed() 成立，函数取出新头，先处理尚不支持的空间层条件，再派生最大尺寸、可见矩形、配置档、位深、色度采样与颜色信息。这些是应用能够认识的配置。与此同时，只要 current_sequence_header_ 已存在，代码就调用 RequiresHardwareContextReset() 计算 structural_change，代表应用看不见的后端契约。

两类结论最终汇入同一个条件。常规格式不同，或 structural_change 成立，都会让 Chromium 更新公开配置字段，取消当前帧的自动清理保护器，并返回 kConfigChange。取消保护器很关键：调用者处理完新配置后还会再次进入解码器，相关状态必须停在正确位置，不能被普通耗尽流程清走。

代码在判断返回前会更新 current_sequence_header_，序列变化时也会清理参考帧。单看顺序可能令人疑惑，回归测试却明确规定了协议：解码器先暴露新配置，上层重建资源，之后再次调用才能继续。安全补丁没有重写解析器，也没有更换加速器接口，只是让更多结构变化进入这条已经成熟的暂停与恢复路径。

常规条件仍承担重要职责。最大帧变大、配置档改变、位深或色度不同，都会让拥有输出表面的组件重新考虑资源。结构判断补上这些可见字段覆盖不到的区域。它与常规条件并排出现，本身就说明分配敏感工具虽然不属于显示格式，却同样决定平台对象能活多久。

下游整合必须把布尔值一路追到返回位置。只找到十五项比较还不够，合并冲突可能使结果没有进入配置条件；供应商也可能用另一个函数名实现等价重置。真正可观察的约束只有一个：任一分配敏感字段变化后，受新头支配的帧不得送入根据旧头创建的加速器。Chromium 无需知道每款 GPU 的临时工作区究竟有多少字节，只需结束旧对象寿命，把控制权交回真正拥有分配的组件，让平台差异在原构造流程中重新计算。

2.2 kConfigChange 是新帧越过前唯一安全关口

上层收到 kConfigChange，便知道必须重新协调对象所有权。与编解码器无关的解码层描述新需求；平台路径拥有表面、受保护会话、命令缓冲以及创建时已经决定布局的驱动对象。返回值制造了一段没有新帧提交的空隙，上层可以排空或放弃旧工作、销毁不兼容上下文、创建替代对象，再回到解码器继续。

若这个返回没有发生，DecodeInternal() 会沿正常路径继续。它请求加速器创建 AV1Picture，准备解析后的帧状态，再由 DecodeAndOutputPicture() 调用 accelerator_->SubmitDecode()。新序列头本身合法，旧表面也曾合法，两者之间过期的寿命关系才是代码没有验证的部分。

ClearReferenceFrames() 不能代替上下文重建。参考帧槽位只是 Chromium 对可用于预测画面的逻辑视图；硬件临时区、编解码器堆、行缓冲或固件表可能附着在上下文本身，在逻辑引用清空后继续存在。修复把工具契约变化提升为上下文所有者必须处理的事件，令上层清理与底层资源代际重新对齐。

完整重建避免了局部修补：只扩大某个已知临时缓冲区，也许能让一款设备停止崩溃，却可能保留另一后端过期的表或命令模板。共享代码只判断契约是否改变，平台代码再把新头应用到全部创建时决策。配置事件、旧上下文退出、新上下文创建和提交代际因此成为稳定验收点，无需让设备真的越界。

异步交接有两道顺序要求：序列 A 已提交的命令必须排空或越过同步栅栏，旧资源才能退休；序列 B 又必须等新代际准备完毕才能提交。补丁把工具变化送进既有的 kConfigChange 路径，沿用尺寸变化的同步模板，既防止销毁过早，也防止创建过晚。

正确轨迹应当出现清晰断点：解析器报告序列变化，重置判断成立，参考状态被清理，Decode() 交出 kConfigChange，调用者重建加速器，上层再次进入后才创建并提交新帧。漏洞轨迹只少了中间的返回与重建，这一小段空白却决定同一幅 720p 画面会不会越过合法内存范围。

kConfigChange 是可恢复控制流，不是解析错误。包裹 AcceleratedVideoDecoder 的适配层必须把它传给真正拥有平台对象的组件并暂停解码循环；把它当成“立即重试”，或只更换无关输出表面，都会绕空这次修复。验收还要分清排空、清空缓冲、清理参考帧与上下文重建：只有最后一项会按新序列创建平台资源，证据必须落到新代际及其第一笔提交。

3 十五个开关写出一张资源清单

3.1 完整比较把编码工具映射到上下文寿命

最终辅助函数看起来是一长串不等式，按资源类别阅读会清楚得多。原有四项是 use_128x128_superblock、film_grain_params_present、enable_cdef 与 enable_restoration；7 月提交又加入 enable_superres、enable_filter_intra、enable_intra_edge_filter、enable_interintra_compound、enable_masked_compound、enable_warped_motion、enable_dual_filter、enable_order_hint、order_hint_bits、enable_jnt_comp 与 enable_ref_frame_mvs。

即便某项字段只有在另一开关启用时才有意义，完整寿命比较仍会直接检查它。辅助函数回答的是整份上下文契约是否保持一致，不负责预测下一帧是否马上走到每条路径。重新创建可以按新序列规范化所有依赖状态；继续复用则要求共享代码和所有后端共同证明某个休眠差异永远无害，证明范围会大得多。

修复使用简单相等判断，没有为字段打风险分，也不在通用层估算内存。任何一项不同都足以结束旧上下文。这个选择很保守，却只发生在编码视频序列转换点，已有重建协议可以承接成本。它避免跨序列保留一套共享代码根本无法检查的私有分配假设。

十五项列表同时产生未来维护义务。以后若 AV1 后端在创建上下文时读取新的序列字段，那一字段也必须加入公共重置判断，或由同等强度的跨后端机制处理。代码评审可以把规则写清：每一处新的创建时语法依赖，都要指出值变化时由哪个寿命比较令现有对象失效。

use_128x128_superblock 位于原四项中，因为它会改变画面被划分和遍历的基本粒度。固定功能解码单元常按块组织元数据、边缘缓存与调度批次，旧上下文如果按 64×64 组织，不能仅凭最大帧尺寸相等就推导 128×128 模式可安全复用。

film_grain_params_present 描述序列是否可能携带胶片颗粒参数。实现可以在输出阶段合成颗粒，也可能为参数、随机状态或额外表面预留空间。它不一定改变解码后画面的几何，却会改变从重建结果到最终输出之间的处理链，因此原实现已经把它视作对上下文敏感的配置。

enable_cdef 与 enable_restoration 控制两类环内处理。CDEF 根据方向性约束去除振铃，环路恢复还可能使用维纳滤波或自引导滤波。驱动或固件可为行邻域、系数与中间样本分配专用工作区。旧上下文没有启用时，后续帧不能假定这些工作区天然存在。

enable_superres 允许编码尺寸与输出尺寸之间出现超分辨率缩放。可见画布仍可保持 1280×720，内部却可能先在较窄宽度重建，再经过上采样输出。表面步幅、临时行与缩放内核都可能参与创建决策，因此它必须与尺寸字段独立比较。

enable_filter_intra 会让帧内预测使用特定滤波模式，enable_intra_edge_filter 又控制预测前的边缘样本处理。二者都作用在块内，并不要求序列最大宽高变化。后端可根据是否启用来选择内核集合、上传表项或分配局部临时区。

enable_interintra_compound 允许把帧间预测器与帧内预测器组合，enable_masked_compound 则允许用遮罩混合多路预测。单路路径和复合路径的中间结果数量不同，硬件可能需要额外读取、权重状态或临时目的地。相同输出画面不代表中间表面数量相同。

enable_warped_motion 打开全局或局部扭曲预测能力，需要变换参数、采样范围与边缘处理。它可能改变参考表面的访问模式，也可能让固件选择不同命令序列。旧上下文若在该能力关闭时创建，不能把新头中的启用当成普通逐帧参数变化。

enable_dual_filter 允许水平和垂直方向选用不同插值滤波器。解码后尺寸保持一致，预测阶段的滤波器选择与系数状态却更丰富。某些实现把这类能力放进会话创建参数，公共解码器因此必须把开关变化视为整个会话失效。

enable_order_hint 决定参考画面的相对顺序信息是否参与语义，order_hint_bits 决定表示范围。位宽变化不仅影响解析值，还可能改变存储掩码、比较逻辑和固件表布局。两个字段一起比较，避免旧上下文按另一位宽解释新序列状态。

enable_jnt_comp 允许根据时间距离对复合预测器加权，其语义与顺序提示紧密相连，硬件实现可以为距离计算、权重或中间预测结果保留状态；enable_ref_frame_mvs 又让参考帧保存的运动矢量进入后续预测，可能要求每个参考帧槽位配有运动场表面或附加元数据。即使 Chromium 清空自己的参考指针，这些资源的大小和格式仍由创建契约决定。

把十五项逐个展开后可以看到，列表并非随意堆砌功能开关。每一项都可能改变块遍历、预测器、滤波器、参考状态或中间存储。Chromium 选择统一重建，是因为共享层无法证明任意组合在所有 Windows、Linux、ChromeOS 与设备驱动上都能原地升级。

同时，列表也不等同于“开启功能一定分配更多内存”。某些后端始终预留最大空间，某些字段只改变固件配置，另一些实现会根据能力精确裁剪。安全判断关注旧分配是否仍有证明，不需要事先知道资源一定变大。只要创建输入不同，重新走一次后端构造便能恢复证明。

3.2 新语法与旧分配组成了无效搭配

不完整比较返回假后，失配过程便很直接。libgav1 已经解析第二段序列，Chromium 保存的当前序列头也允许新工具；驱动对象却仍按第一段序列创建。后续帧一旦选择刚启用的操作，Chromium 就会把相应参数送给后端，固定功能代码随即踏进旧上下文从未备齐资源的路径。

提交说明确认可能出现越界读写，却没有给出一种跨平台通用的利用条件，这一点非常重要。在一款 GPU 上，缺少临时工作区可能令命令遭拒或设备重置；换一款设备，固件索引也许会越过私有缓冲区；还有一些实现因为预留较多而没有明显症状。所有平台共享的是过期的分配契约，最终访问落在哪里则由具体后端决定。

越界读可能把相邻的解码器或驱动数据带入后续计算，也可能直接触发故障；越界写会破坏附近 GPU 可见状态，完整性后果更重。Chrome 公告将它列为“编解码器中的越界读写”，并评为高危。公开资料尚未建立稳定的跨平台利用链，但已经证实的内存安全影响和广泛媒体入口，足以支持立即处置。

浏览器与 GPU 进程之间的隔离会影响后果，却不改变根因。硬件媒体操作通常位于受沙箱约束的进程，再通过系统接口访问权限更高的驱动。内存破坏可能落在 Chromium 用户态媒体代码、厂商库、内核驱动状态或固件管理内存，取决于后端。沙箱与驱动校验能够削弱某些后果，却无法补上那个允许旧上下文继续存在的错误判断。

序列头本身无需违反 AV1 规范。两段编码视频序列合法声明不同工具能力，本就是解码器必须处理的情形。媒体来源能够控制转换时点，所以合法语法在对象寿命上仍属不可信输入。完全拒绝工具变化会破坏兼容性，重建上下文则既保留规范行为，也沿用 Chromium 已有的安全配置通道。

参考帧清理把上下两层的区别展示得最清楚。Chromium 可以清空可供预测使用的帧数组，阻止新帧跨序列引用旧画面；平台上下文里的堆、概率缓冲区、命令模板或能力位却仍可能保留。上层逻辑为空，不代表下层物理资源与新契约兼容。重置信号必须完成这次所有权交接。

只从崩溃栈开始调查往往太晚。驱动故障出现时，真正导致问题的序列转换和上下文创建可能已经落后好几个异步调用。测试期可在重置判断和提交关口记录新旧十五字段向量、structural_change、上下文代际，以及新提交前是否出现新的代际值；这些信号比最终模块名更接近原因。

部署也无需先找出每款 GPU 上究竟哪一个字段会破坏内存。产品若含有不完整决策，并能让攻击者影响的 AV1 进入硬件路径，就需要修正上下文寿命。后端测试用于证明补丁真正接入并发现集成回归，不负责决定共享源码缺陷是否值得修复。

在 Windows 路径上，Chromium 可能经过系统媒体接口与厂商用户态驱动；Linux 和 ChromeOS 则可能使用不同的 VA-API、V4L2 或平台专用加速路径。资源所有权、错误返回和设备重置方式并不统一。公共修复选择在这些分支之前结束旧上下文，正好覆盖了后端差异开始扩散的位置。

受保护内容路径还可能引入受保护表面、密钥会话与受限映射，症状和普通解码不同。公开补丁没有把 CVE 限定在某一内容保护模式，资产判断也不应凭“只播放加密流”自动排除。只要同一共享 AV1Decoder 决定上下文寿命，就应采用固定源码证明。

驱动拒绝命令是一种可能的防御结果，却不能当成 Chromium 的安全属性。供应商校验也许在某个版本恰好发现资源缺失，换一个组合却可能继续执行。把不兼容输入拦在提交前，才能让正确性不再依赖每个驱动对过期会话的二次判断。

同理，某台测试设备“从未崩溃”只说明当前组合没有产生可见故障。过度分配、未触发对应帧工具、错误恢复或遥测缺失都能隐藏症状。源码谓词与配置事件是确定性证据，稳定播放只能作为兼容性检查，不能替代安全验收。

重建时点必须落在接受新序列头的那一刻，不能推迟到第一张真正使用某项工具的帧。序列头已经允许后续帧选择这些路径，命令构造也可能在明显使用之前准备表项或能力参数；异步后端甚至会让工作先进入队列。统一在这个序列头接受点交还所有权，能够给全部平台一个确定关口，避免共享层猜测每个后端何时才算“真正用到”新资源。

硬件能力查询回答的也不是当前上下文是否兼容。驱动可以报告设备总体支持环路修复、扭曲运动或参考帧运动矢量，这只证明它能为序列 B 创建新会话，不能证明按序列 A 创建的对象已经预留相应资源。后端证据应分别保存全局能力结果、当前上下文的创建描述或十五字段摘要，以及每次提交使用的代际值，把“这块 GPU 能做”与“这个对象生来就能做”分开。

越界读写的对象也不宜在提交说明之外擅自细化。公开材料没有说明具体缓冲区、偏移、攻击者控制程度或跨沙箱链。文章采用“新语法授权旧分配未准备的路径”这一得到提交记录支持的模型，同时把不同后端的实际访问位置留给可验证日志与厂商分析。

保持这样的证据范围不会降低修复优先级。硬件视频解码面对网页和嵌入应用提供的大量非可信媒体，高危越界读写已经足以要求快速升级。精确表达未知部分，能让调查者以后接入新的驱动公告或崩溃材料时，不必推翻已经确认的根因。

4 两段字节数组把画布牢牢按住

4.1 序列 A 与序列 B 只改变工具契约

回归测试把寿命论证压缩进两段内置输入。kSequenceA 与 kSequenceB 位于 av1_decoder_unittest.cc，都不是包含大量变量的通用合规视频。它们只保留足以让解析器和模拟加速器经过目标路径的 AV1 结构，第二段再精确隔离旧重置逻辑遗漏的工具转换。

测试注释明确写出反向控制：两段序列尺寸相同、配置档相同、位深相同、色度采样相同，128×128 超级块选择也相同。任何常规格式变化都能让旧实现返回 kConfigChange。若测试在切换顺序提示的同时改了宽度，绿灯只能证明旧宽度判断仍在工作，无法证明新谓词被调用。

序列 A 建立基线。解析得到的头关闭顺序提示，也关闭参考帧运动矢量。模拟加速器创建帧对象、接收解码提交并输出，测试保存 SubmitDecode() 实际看到的序列头。这样，后续断言来自真正交给加速器的结构，不必单凭手工字节推测解析器状态。

序列 B 固定常规配置，只改变回归所需的分配敏感集合。捕获的头中顺序提示与参考帧运动矢量被启用，order_hint_bits 也不同，字节流同时切换其他新覆盖工具。测试目标不是宣称某一字段在所有后端都能单独制造越界，而是证明旧四项仍相等，完整十五项却已经代表另一份契约。

模拟调用预期保证两边都完整走通。两段输入各自预期 CreateAV1Picture()、SubmitDecode() 和 OutputPicture()。若测试检测到头变化后立刻结束，就可能错过恢复过程消费状态的错误。两帧都能完成，说明配置暂停可以恢复，第二段最终在重建后的条件下提交。

捕获头还断言最大宽高和 use_128x128_superblock 相等，再断言顺序提示、参考帧运动矢量与提示位宽不同。这种解析后的成对比较比直接比较原始数组更稳：它证明 libgav1 把输入解释成预期语义。未来若样例被改动或解析器行为变化，失败会直接指出哪项控制发生了移动。

回归关联缺陷编号 520565945。即使详细问题单在多数用户更新前仍限制访问，公开提交、评审记录、文件路径、测试名和字节数组已经构成可迁移的证据包。下游不需要私有崩溃媒体，也无需寻找一块会越界的 GPU，便能重现共享解码器应发出的寿命事件。

4.2 第二次配置事件证明重建确实发生

每段数组对应的期望结果顺序都是 kConfigChange，随后 kRanOutOfStreamData。前一个结果让调用者按序列建立配置，后一个说明恢复解码后已经耗尽当前缓冲区。要求这组结果出现两次，便把第二次配置事件变成明确观察值，不再依赖某个驱动恰好没有崩溃来反推安全。

旧代码处理序列 A 时，因为此前没有上下文，初次配置事件本来就合理。真正区分新旧实现的是序列 B：尺寸和早期结构字段都相等，不完整的辅助函数返回假，第二次事件随之消失。测试恰好在协议缺口处失败，因此不必等到内存破坏发生，也能证明漏洞存在。

修复后，完整字段集合中的任一不等都会令 structural_change 为真。DecodeInternal() 会在提交下一帧之前返回。模拟单元测试不创建真实平台驱动对象，却证明共享解码器已经发出供实际所有者重建的信号；后端集成测试再围绕同一信号验证销毁与构造。

这种分层测试比崩溃复现稳定得多。崩溃依赖 GPU、驱动、分配布局与异步调度，分配器改动甚至可能令症状暂时消失，而寿命错误依然存在。单元测试固定所有后端共享的配置契约，集成测试固定具体平台的先后顺序，二者都不需要尝试越界访问。

定向命令就是 media_unittests --gtest_filter=AV1DecoderTest.ConfigChangeOnSequenceHeaderToolFlags。它的价值在于具体：输出必须证明该测试样例确实匹配并执行，两组序列数组也确实产生两次预期配置事件。旧分支可以改测试套件名称，却必须保留测试样例与断言；一张笼统的媒体测试套件绿灯说明不了这次转换。

供应商还可以在语法允许范围内增加逐字段用例：固定整份头，只改变一个重置字段；存在依赖的工具组合则按 AV1 规范构造合法配对。每一例都应断言解析前后值、第二次 kConfigChange，以及旧上下文代际上没有出现新提交。

反向用例同样重要。两个完全相同的序列头不应无谓重建，普通尺寸变化仍应走原配置路径，工具变化后跟着坏帧时也应先发出配置事件再报告后续解码错误。这些检查同时守住性能与状态顺序，把安全性质明确限定为：所有创建敏感输入相等时，旧对象才可继续。

两段数组最终把故事拉回开场。应用依旧看到相同的 720p 格式，只有解码器私有契约发生变化。修复后的测试在 Decode() 返回点让这份不可见差异显形；后端的具体症状尚未出现，根因已经被拦在关口内。

几组对照把寿命判断的正反两面都钉住：A→B→A 应在每次契约变化时重建，B→B 不应无谓重建；拆分缓冲区要等完整序列头到齐才触发一次转换，把 B 作为新解码器首个输入则只应走初次配置。它们共同证明第二次事件来自跨时间兼容判断，而不是 B 本身被特殊处理。

模拟调用必须约束先后，不能只数次数；否则实现可能先在旧上下文提交，再补发配置事件，测试仍然通过。字节数组也不能作为无解释的“魔法常量”维护：保存数组源码与测试二进制哈希，用解析字段说明每个差异和负控，并明确要求配置事件和新代际早于序列 B 的 SubmitDecode()。

无法运行完整 media_unittests 的嵌入产品，可以在共享源码树执行上游用例，以构建来源绑定生产库修订，再在设备上验证上下文代际。缺少的测试层应列为剩余风险；无论采用哪种组合，序列 B 都必须在提交前完成重配置，一台样机播放正常不能替代这条先后关系。

5 两次提交修好判断的两个层次

5.1 六月重构先抽出四字段关卡

第一项公开变更在 6 月 10 日进入主线，提交为 f77363617210dd46fb5b7f765c4da1af718a7393，父提交是 b4fe89207b09b04c195cce1919492feba57b008d，评审编号 7912486，提交序号为 #1644968。主题明确写着重构 AV1 序列头验证并修正硬件上下文失效处理。

该变更从较大的序列变化代码块中抽出 RequiresHardwareContextReset()，让上下文失效成为一个有名字的概念。辅助函数集中比较超级块、胶片颗粒、CDEF 与环路修复四项，显示配置判断和工具驱动的上下文判断由此分离。结构更清楚，也为后续补全提供了准确落点。

重构只修改 media/gpu/av1_decoder.cc，没有加入最终提交里的双序列回归，也没有覆盖后来确认的十一项字段。因此，下游源码里出现同名辅助函数，并不能证明漏洞已经修复。函数形状只能说明分支走到中间阶段，完整成员与测试行为才是更强证据。

时间线需要精确。早期原稿把这次重构写成 6 月 22 日，公开 Gitiles 记录实际为 6 月 10 日。对于夹在两次提交之间构建的快照，这十二天差异会影响判断。6 月 10 日之后的代码可能看起来已经“现代化”，却仍没有 7 月 1 日的完整资源清单。较早基线也可能回移完整补丁，较晚分支则可能漏合或回退；提交图、实际差异与回归结果必须合在一起判断。

两个父提交提供了干净的差异基线。从 b4fe8920 到 f7736361，可以只看辅助函数抽取与原有四项范围；从 353326bb94b506c10d0ebe3e40f5b34cbf015ccf 到最终修复，则能单独看到十一项新增与测试。分阶段查看差异，可以防止安全补全被误读成一次单纯整理。

这次重构也暴露了一个工程规律：给寿命决定起名字是必要一步，谓词强度仍由背后的资源清单决定。共享解码器不能从字段名称猜测每个后端的分配依赖，必须汇总创建时读取的字段，再用输出不变、内部需求变化的测试守住。7 月提交正好补上这两块。

5.2 七月修复补齐清单并用测试锁住

最终提交 48c725cd3ed15bad33f5efad89103dd7cbc11be6 于 7 月 1 日落地，父提交为 353326bb94b506c10d0ebe3e40f5b34cbf015ccf，评审编号 8021903，提交序号是 #1655533，作者为 Sangwhan Moon。按状态机阅读，每个新增不等式都连接着两份序列快照：任一创建敏感事实发生变化，旧上下文寿命便结束；返回假，则正面承诺完整字段集合仍然兼容。下游可以用这些标识和语义共同核对祖先关系或等价回移。

代码差异很集中：RequiresHardwareContextReset() 的返回表达式增加十一项字段；media/gpu/av1_decoder_unittest.cc 新增 ConfigChangeOnSequenceHeaderToolFlags、两段字节数组、模拟调用预期与字段断言。源码改动定义寿命判断，测试保存导致判断变化的同格式输入；两者缺一，证据都会变薄。

调用处只在已有旧头时计算 structural_change，初始序列因尚无可复用对象，本来就会走初次配置。这也解释了为什么测试必须在同一个解码器实例中连续喂入 A 和 B。若每段序列都使用新测试样例，兼容性问题根本不会被触发。

序列变化后，代码更新 current_sequence_header_ 并清空参考帧；配置条件为真时就返回，下一次调用再从新头继续。上层必须在收到事件后、重新进入解码器前完成重建。下游若丢掉事件并直接重试，即使辅助函数完整，也可能在适配层重新制造同一寿命错误。

当前帧的自动清理保护器也属于恢复协议。配置返回不是普通缓冲区结束，自动清理不能擦掉重配置后继续所需的状态。最终提交没有发明新暂停机制，只让更多序列变化激活成熟路径。这种小范围改动使测试结果更容易归因，也减少了新的所有权风险。

文本回移仍可能失败：旧 libgav1 结构可能字段改名，合并时可能漏掉一项不等式，功能条件可能在某些构建中隐藏字段，平台分支还可能绕开 AV1Decoder。验收要编译实际产品配置，寻找替代的 AV1 加速器入口，并在相同构建开关下运行转换测试。

供应商也可以采用等价设计，例如任何序列头变化都无条件重建 AV1 上下文，或把完整比较移到平台中立配置对象。只要新序列绝不会进入旧分配，并且同格式工具转换回归能够证明行为，就满足安全性质。供应商需要用源码或测试说明等价关系，不能只给出“已更新”一句话。

更多转换触发重建后，性能也应进入验收。代表性视频要测量切换延迟、掉帧、表面周转、功耗与不同 GPU 家族表现，退化只能在安全寿命模型内优化。相邻硬件编解码器也应沿同一方法审计：列出创建上下文时读取的语法元素、指出失效比较，并用外部输出不变而私有需求变化的序列覆盖。

Gitiles 与 Gerrit 提供互补的来源证明。Gitiles 固定落地主线树、父提交、两份文件的差异、作者与提交序号；评审 8021903 保存评审身份和补丁演进；Chrome 公告再把上游变更映射到产品线。下游应保留这三层证据，避免只凭相似的辅助函数名称关闭条目。

维护清单应把每个重置字段映射到平台使用方、资源类别和回归用例。以后只要持久 AV1 上下文构建读取新的序列头成员，改动就必须指出对应失效规则，并增加公开格式不变、私有需求变化的转换用例；遗漏的创建依赖由此不会继续藏在后端经验里。

同时编译多种 AV1 后端的产品，要按实际交付变体保存源码、集成与软件包三层证据：共享解码回归在相关配置中执行，真正启用的每条平台路径都验证代际顺序，最终结果再绑定签名包和功能清单。某个关闭后端的构建通过，不能替另一份启用该后端的软件包作证。

6 一套 Chromium 解码器走进多种硬件后端

6.1 产品版本与提交祖先回答不同问题

Chrome 7 月 8 日稳定频道公告划出了产品发布线：CVE-2026-15114 被列为编解码器中的高危越界读写，Google 报告日期为 6 月 6 日；Windows 与 macOS 修复发布线为 Chrome 150.0.7871.115 或 150.0.7871.114，Linux 为 150.0.7871.114。相邻构建号同属一次安全发布，不能把“低于 .115”机械套到所有平台。

受管 Chrome 设备应安装各自渠道提供的平台包，并保存软件包标识、签名结果、渠道、操作系统与安装时间。这份记录只证明交付物跨过了对应平台的版本下限，尚不能说明内存里正在执行哪份映像；下文的独立进程检查再补上运行时事实。

Chromium 衍生产品不会自动跟随 Chrome 外层版本号同步。Electron 客户端、CEF 外壳、Qt WebEngine、嵌入式浏览器、测试运行器与厂商媒体产品都有自己的源码快照和发布节奏。对这些产品，提交 48c725cd3ed1 或有文档支撑的等价回移才是精确源码分界，供应商还必须把它映射到可部署的产品版本。

提交序号 #1655533 可用于排列上游快照，却不及祖先关系有力。看起来更晚的下游分支可能漏合、回退，或在冲突中损坏补丁；较早的长期支持分支也可能携带完整回移。源码可见时，要检查祖先关系或补丁等价性，并同时核对辅助函数与回归；只有二进制文件时，则应要求厂商给出包含修复的 Chromium 修订。

CVE 记录和 Chrome 公告说明严重性与产品行动，已经落地的提交说明根因与源码改动，AV1 规范说明字段与序列转换属于合法格式。三类来源各自回答不同问题。产品公告无法证明十五项精确列表，源码差异也无法单独证明哪一个签名软件包已经交到终端用户手中。

Linux 发行版可能重新构建 Chromium，并添加自己的软件包修订。安全跟踪记录或变更日志可以声明 CVE 已修复，即便浏览器展示版本与 Google 的字符串不完全相同。管理员应采用发行版给出的固定包证据，并确认实际可执行文件路径；Chrome 官方发行版、发行版 Chromium、Flatpak、Snap 与应用内置引擎是彼此独立的处置单元。

固定发布线还给调查提供了时间分界。旧构建上的 GPU 故障，在来源证明确认回移之前，都与脆弱源码路径相容；修复构建上的故障也不能自动排除不完整回移、下游集成错误或另一个媒体缺陷。保留修订与后端事实，才能把源码状态和外部症状分开。

Chrome 公告中的两个相邻构建号还提醒资产系统不要截断版本字段。若清单只保存 major.minor.build，150.0.7871.114 与 .115 会被混成同一记录；若只拿最高补丁号比较，Linux 正确的 .114 又可能被误报。应采集完整四段版本，并把操作系统与渠道一起作为判定键。

Chrome 稳定频道、扩展稳定频道与下游企业包的发布日期也可能不同。管理员应以产品渠道公告确认本渠道已包含修复，不能仅凭上游稳定频道在 7 月 8 日发布，就假设所有长期支持设备已经收到。更新策略、代理缓存和分阶段推送都可能造成数日到数周偏差。

多进程浏览器的重启证明要覆盖 GPU 进程。关闭所有可见窗口后，后台模式、扩展宿主或通知进程可能继续存活，随后复用旧 GPU 子进程。企业发布可以使用厂商支持的重新启动流程，验收时记录主进程与 GPU 进程启动时间，并确认二者都晚于固定包落盘。

向下游供应商提问时，应要求安全产品版本、发布日期、内含的 Chromium 修订、补丁是直接合入还是等价回移、更新后是否必须退出应用，以及哪个组件承载 AV1 硬件解码。只有“产品不受影响”四个字，无法区分源码不存在、硬件路径不可达、已有修复或尚未完成分析。

源码不可见的商业应用可以从多项材料拼出来源链：安装包清单、模块文件版本、符号字符串、供应商 SBOM、发布说明与支持工单。任何单一线索都可能失真；至少需要厂商正式映射，或可重复的二进制文件到源码修订证明，才能把条目从“待确认”关闭。

旧回滚目录值得单列。自动更新器为失败恢复保留上一包时，正常启动使用固定引擎，某次回滚却可能重新激活脆弱版本。处置要确认回滚策略不会越过安全下限，或使旧包失效；简单删除目录可能破坏更新器状态，应按产品支持方式执行。

SBOM 中只写“Chromium 150”同样不够。该主版本内包含修复前后的多个快照，媒体组件还可能由供应商单独挑选提交。理想记录应同时保存外层产品版本、完整 Chromium 提交、补丁来源与产物摘要，使以后的编解码器漏洞也能沿同一条链快速判断。

离线和封闭网络设备并不会因入口少就自动安全。数字标牌可从 U 盘、内容分发节点或维护接口接收视频，审核终端会处理内部上传，测试机还可能打开抓取样本。它们的更新周期通常更长，应根据媒体来源与硬件能力安排固定包，而非等待浏览器自动更新。

风险排序可以把四项事实放在一起：是否含脆弱修订、是否能选择 AV1 硬件解码器、是否接收不可信媒体、是否存在稳定快速的更新路径。前两项决定技术可达，第三项影响触发机会，第四项影响暴露时间。任何排序都不改变最终需要修复的源码范围。

版本证据最终要落到运行单元。桌面设备按可执行文件或模块，容器按镜像摘要，服务器按部署修订，嵌入固件按签名包，浏览器测试缓存按下载键。用相同 CVE 状态覆盖整台主机，会抹掉多个独立 Chromium 副本之间的差异。

6.2 实际可达性取决于真正选中的硬件路径

源码存在与运行时可达是两层暴露。问题位于 Chromium media/gpu 中的 AV1 解码器；只有产品实际使用该解码器，并选择会依据序列字段分配上下文资源的硬件加速后端，才会走到旧上下文复用条件。没有 AV1 硬件能力的设备可能回退软件路径，但能力、策略、驱动与负载都可能变化，仍需安装厂商修复。

资产盘点先找会接收外部视频的产品。浏览器渲染网站媒体，协作客户端预览消息和会议流，内容审核工具打开上传文件，数字标牌与自助终端拉取排期素材，桌面外壳可经嵌入网页暴露媒体，自动化测试系统还会访问任意页面。用户无需主动打开独立播放器，序列转换已经能进入解码管线。

硬件选择是动态结果。同一个可执行文件，在不同 GPU、驱动、远程桌面会话、虚拟机、节能模式、沙箱策略或企业配置下，可以选择完全不同的路径。实验室电脑显示软件解码，不能证明带 GPU 直通的生产自助终端也相同。应在真实业务会话中记录解码器、GPU 厂商和设备标识、驱动程序包、操作系统与相关策略。

Chromium 媒体诊断页能用受控的良性 AV1 样例显示所选解码器，产品日志或内部页面也可能标明硬件加速；若产品没有可见接口，可由供应商提供受支持的调试日志，或在测试构建中临时观察加速器构造。这类检查只用于确认路由，不需要喂入未知的崩溃媒体。将可疑样本投放到生产设备会放大风险并污染证据，版本与源码证明始终是修复判据。

一个全局“已启用硬件加速”开关仍然太粗。GPU 可能只加速页面合成，AV1 继续走软件解码器；同一设备上的不同配置档、位深、分辨率或受保护内容路径，也可能选择不同后端。路由证据要写明编解码器、配置档、样本特征、实际解码器与观察所在会话，不能把一次图形检查或 H.264 成功播放借来证明 AV1 硬解。

驱动更新可能强化校验，或让某一种崩溃暂时消失，仍不能完成 Chromium 修复。共享解码器依然会宣称不兼容上下文可以复用，未来硬件、另一驱动分支或新工具组合仍可能暴露。调查 GPU 故障时可以按厂商建议更新驱动，关闭 CVE 则必须证明产品含有完整重置比较。

一个安装目录还可能包含多份引擎。更新器、主界面、插件宿主、崩溃报告器与测试浏览器可以携带不同 Chromium 库，回滚目录里又保留旧版本。资产证据要把可执行文件与它实际加载的模块路径、修订绑定；卸载注册表或管理控制台中的展示版本，无法单独回答运行时用了哪份库。

容器与云端工作负载同样需要逐层确认。基础镜像可能安装系统 Chromium，应用层另行下载测试浏览器，持续集成缓存保存快照，固定镜像发布后，长期运行的容器也不会自动替换。把镜像摘要、浏览器缓存键、部署修订和容器创建时间接起来，才能证明新实例真正使用了修复组件。

文件扩展名、MIME 类型标签和外层容器同样不能可靠说明路由。产品可以从常见媒体容器中分离出 AV1，也可以从另一组件接收裸码流，或先把上传内容交给缩略图生成器；主播放器尚未出现，解码已经发生。内容拼接、直播编码器重启或内部转码都可能带来合法的序列转换，而应用仍显示同一名义格式。资产证据必须落到实际解析的编解码器、观察到的序列转换和解码点选择的后端；素材目录标签或 CDN 文件名回答不了这些问题。

发布期间若临时禁用硬件解码，必须在每个产品完整重启后证明真实路由：普通应用会话、子进程、嵌入视图，以及带自定义参数启动的服务都应选择软件解码器。记录 CPU 占用、功耗、风扇表现、掉帧、负责人、到期日和撤销条件——固定模块已在真实进程中激活。这份带日期的路由记录才是临时控制证据，设置页开关不是。

部分下游包通过独立媒体仓库与 GitOrigin 修订标识组件。使用这种来源证明时，应同时保留媒体镜像标识及其映射的 Chromium 提交，避免清单没有外层哈希，就把已经修复的媒体源码树错判为未知。

7 第一份有用证据通常出现在 GPU 进程

7.1 崩溃必须带上构建、后端与序列转换上下文

现场几乎不会直接显示 CVE-2026-15114。用户看到的可能是 GPU 进程退出、解码器重置循环、驱动超时、设备移除、视频画面冻结，或图形栈重启后自动恢复的标签页。这些症状也会出现在普通硬件故障和其他媒体缺陷中。只有把它们与受影响构建、AV1 硬件路径和十五字段转换关联起来，才会产生辨识力。

相关事件还可能跨越多个进程与时钟域。Chromium 可以在一个组件解析，由 GPU 进程持有加速器，再调用操作系统媒体服务或固件，最终故障却记录在另一处。配置返回、上下文构造、第一笔提交与设备错误，应通过不含媒体内容的会话标识、规范化时间戳和各进程模块修订关联起来。顶层栈落在驱动里只能算弱线索；浏览器进程号没变，也不能证明 GPU 或媒体服务的代际没有重启。

任何复现之前，先收集版本事实：完整产品版本、可执行文件路径、包来源、能够获得的 Chromium 或媒体组件修订、进程启动时间、操作系统、GPU 厂商和设备标识与驱动版本。再记录影响加速的策略和命令行开关。虚拟机或远程环境还要记会话类型与设备直通状态；这些信息决定故障时究竟是哪一个解码器和上下文实现在工作。

媒体管线证据补上第二层。保存实际解码器名称、编解码器配置档、编码尺寸与可见尺寸、颜色配置、配置变化事件，以及诊断界面能提供的 GPU 上下文标识。若策略允许记录解析字段，只需保存相关新旧值与时间戳，便能判断创建资源所依赖的字段是否发生变化，以及下一次提交前是否创建了新上下文。

崩溃产物也要放进同一时间线。浏览器转储、GPU 进程转储、系统事件、驱动重置报告与应用日志可能采用不同时间基准，需要统一后保留原始时间戳。顶层栈可以落在 Chromium、厂商用户态驱动、系统媒体库或通用设备丢失处理器。没有构建与转换背景，模块名本身不足以识别根因。

政策允许保存源媒体时，应计算加密哈希、原样封存、记录取得路径并限制访问，不能把它当作普通测试视频传播。调查可以先在隔离流程中解析是否存在多个序列头、哪些高层字段变化，再决定是否需要进一步受控复现。很多问题用公开单元回归已经能够回答，不必让未知样本进入更多设备。

没有转储也不能证明没有问题。GPU 自动恢复可能丢掉易失状态，隐私设置可能隐藏媒体网址，固件故障甚至只留下通用设备重置。同一脆弱版本、同一 GPU 家族与同一媒体对象周围出现相似事件，仍值得聚类审查；反过来，缺少任何 AV1 证据的单次驱动超时也不应直接归因。

公开来源没有报告已经确认的在野利用。这句话界定的是当前证据，不能替历史故障开具无害证明。沟通可以准确写明：硬件编解码器上下文寿命存在高危内存安全缺陷，Chrome 已发布修复，公开材料尚未建立完整利用链。版本处置无需等到攻击归因成立。

解释崩溃地址前先按阶段分类。新序列头尚未被接受就失败，更像语法或传输处理问题；配置期间失败，应检查资源拆除与分配；序列 B 已在未变化代际上提交后才出故障，才最贴近过期上下文条件。阶段模型能防止把所有 AV1 故障塞进同一个桶。

生产构建未必暴露上下文代际。此时可以组合最后一次配置变化事件、加速器创建和销毁消息、解码器选择日志与转换后第一笔提交时间。带显式代际值的金丝雀构建可先标定各后端这些替代信号的样子，为生产调查提供书面解释。

聚类有两个方向：同一媒体哈希在多台设备故障，更像内容关联投递；许多无关媒体哈希只在同一 GPU 和驱动组合故障，更像平台不稳定。无论哪一类，都要再连接受影响构建与创建敏感转换，本 CVE 才能成为强解释。

固定构建对照应关注寿命轨迹，不追求再造故障。在隔离流程解析封存样本，确认相关序列转换，再证明修复构建会在提交前抬起配置事件并更换代际。即使分配器或驱动差异令旧症状无法重现，这条结果仍然建立了完整的修复因果链。

7.2 低噪声遥测可以缩小范围，不必把媒体变成探针

有效检测可以从很低的采集量开始。围绕 AV1 会话统计配置变化与硬件上下文创建，并用保护隐私的会话标识关联。固定代码遇到工具字段变化时，应产生对应的代际更新；若转换后仍在同一上下文代际上提交，测试或金丝雀遥测就已经直接捕获寿命不变量被破坏。

生产环境未必适合暴露全部十五字段，大规模保留原始媒体语法也会带来隐私和数据治理问题。一个紧凑的变化位图、后端名称、构建标识与上下文代际计数器通常足够。位图只记录哪些重置类别发生变化，不保存画面内容或网址，访问与保留周期沿用组织现有媒体遥测规范。

金丝雀构建最适合记录详细轨迹。测试期在 RequiresHardwareContextReset() 记录新旧字段向量、布尔结果与单调代际值，在加速器所有者处记录资源拆除与构造，在提交点只记录代际。受控的良性测试样例穿过每个支持后端后，期望顺序就可以机械断言。

升级后可比较前后的 GPU 故障率，却不能把安静曲线当作唯一证明。脆弱转换本来就可能罕见，部分上下文也会因为过度分配而不出现明显错误。软件包来源、进程重启、上游回归与后端顺序测试提供确定证据；遥测负责发现漏网资产与异常集成行为。

8 第二帧越过之前，柜子必须已经重建

8.1 发布证明要连接源码、产物、进程与序列转换

源码验收先看完整谓词。检查目标分支中 RequiresHardwareContextReset() 的等价实现，逐项核对十五字段，再确认已有序列头变化时，调用方会执行它，并把结果放进返回配置事件的条件。继续向下追踪，必须证明新头下的帧在创建或提交前，解码器就已经返回。

在候选发布配置中运行第 4 章的序列转换回归，把源码修订、工具链、构建参数、架构、完整结果和候选测试二进制文件摘要，一并归入同一个发布标识。核对两段数组都被解析成相同常规格式、不同工具状态，并各自产生 kConfigChange 与 kRanOutOfStreamData。

下游适配不能只接受一个改名后的绿灯。第二段输入仍须避开全部常规格式触发条件，捕获头的最大宽高、配置档、位深、色度与超级块选择必须相等，预期分配敏感值必须不同。扩展字段用例还要遵守 AV1 依赖并断言解析值，确保失败确实指向上下文重置契约，不会提前落在语法校验；模拟或集成测试框架则要证明解码能够恢复，第二帧最终到达新上下文。

后端验收直接观察所有权交接。平台上下文创建时分配代际值，输入序列 A，完成第一次配置与解码，再输入序列 B；断言再次产生事件，旧代际被销毁或退休，新代际出现，后续提交只使用新值。组织实际支持的 GPU 家族与驱动分支都应覆盖。

回归范围还要包含正常行为：单一稳定序列、合法尺寸变化、连续相同序列头、胶片颗粒转换，以及普通跳转与清空操作。检查参考帧清理、输出顺序、表面数量和恢复逻辑都正确。补丁改变对象寿命判断，因此测试既要抓住过期复用，也要发现无穷重建。

源码通过后，还要沿编译、签名、符号处理、应用打包、安装器与渠道重封装追到最终产物。测试所用源码、工具链、构建参数和二进制摘要必须映射到签名包；再从最终包提取承载解码器的模块，核对全新安装与各类增量升级都得到同一修复产物。中间构建通过，不能代替交付证明。

字段清单逐项记录目标分支成员、比较式和版本条件，并保留三处调用证据：谓词成立、综合条件返回 kConfigChange、所有者据此创建新加速器。定向测试日志必须显示 AV1DecoderTest.ConfigChangeOnSequenceHeaderToolFlags 确实匹配、执行并通过，而不是筛选器拼错后零用例成功退出；后端轨迹则使用单调代际值，避免对象地址复用把正确重建误判成旧对象复用。

金丝雀矩阵按真实设备份额覆盖主要 GPU、驱动、操作系统和实际 VDI 路径，并记录解码器选择、代际变化、输出、内存与普通播放。旧代际上提交是安全阻断项；重建带来的延迟、掉帧或功耗问题属于性能缺陷，应在不放宽谓词的前提下优化。ASan/UBSan 看不到的驱动或固件内存、GPU 重置后的隐藏软件回退，以及 A→B→A 多轮后的资源泄漏，都要靠顺序、路由和资源记账分别排除。

离线设备、尚无固定包的嵌入产品或金丝雀播放退化可以形成发布例外，但例外必须记录资产、原因、安全下限、复核时间和恢复条件。固定引擎尚未安装并由真实解码进程映射时，条目仍然开放；例外本身不是修复。

发布记录保留源码、测试、软件包、进程和代际证据。若资产关联可疑的更新前故障，直接关联第 7 章的固定构建对照，不重复实验；只有候选版本通过上述链条，授权对照完成，且剩余差异已有明确下一步，才能关闭。

8.2 最后的验收重新回到同一幅 720p 画面

最终构建记录保存 GN 参数、编译器与链接器、架构、功能开关、源码和依赖修订，并从签名包重新提取解码模块与测试清单对照。全新安装和每种实质不同的增量路径都要得到相同模块；金丝雀还应实际尝试一次回滚，证明不安全目标会被拒绝或在启动前补正，而不是只检查一项配置值。

运行时证据来自真正拥有解码的进程：固定包先安装，旧 GPU 进程退出，新进程从该安装启动并映射正确模块，良性转换最后在新代际上完成。辅助进程若从回滚、并列或用户目录加载，磁盘上那份签名包就不能替它作证；跨主机或容器汇总时，还要保留顺序标识或时钟偏差。

源码祖先、字段清单、测试日志、产物摘要、部署记录、进程版本和代际轨迹归入同一发布标识。发布后监测只负责寻找漏重启、异常回退和兼容性回归，不替代确定性修复证明；后续若披露具体后端或缓冲区，既有 GPU/驱动矩阵与封存故障可用于定向重判。每个适用层都有直接观察、每个剩余缺口都有下一步，才算关闭。

1. 先建立资产台账。 列出每个含 Chromium 媒体组件的产品与可执行文件，再记录包含修复的厂商版本或源码提交、安装与进程重启、真实 AV1 硬件可达性，以及双序列回归或供应商证明。每个资产只有在全部适用项完成后才可关闭。
2. 按暴露面安排修复顺序。 先处理互联网入口和自动渲染媒体的产品，再覆盖内部、离线与专用应用。浏览器自动更新不会替换应用内置引擎，因此还要查重复安装和回滚目录，并要求供应商给出 Chromium 修订与上下文重置覆盖。
3. 保全少量真正易失的现场材料。 事件流程需要时，在重启前从少数获授权的可疑更新前设备采集内存转储与 GPU 日志；这些取证样本与大规模发布分开管理，不能拖延其余资产安装固定包。
4. 重启并证明运行模块已更换。 轮换浏览器、GPU、辅助进程、自助终端会话和容器实例，确认新进程启动时间晚于软件包安装，并映射固定模块路径或修复镜像摘要。只看磁盘文件不能关闭条目。
5. 运行安全的序列转换验收。 在受控金丝雀群组使用符合公开回归语义的良性码流——仍是 720p，但工具契约变化——要求提交前出现配置重置和新上下文。验收只观察寿命交接，不尝试制造内存破坏，也不依赖脆弱驱动。

对外沟通只写证据支持的结论：CVE-2026-15114 是 Chromium 编解码器中的高危越界读写，根因是创建资源所依赖的序列字段变化后，仍继续复用 AV1 硬件上下文；Chrome 在 7 月 8 日发布固定桌面构建；公开记录没有给出完整的跨平台利用链，也没有确认在野利用。行动仍是快速更新并重启所有受影响的 Chromium 运行时。

这条工程经验不只属于 AV1。图像处理器、神经网络加速器、解压引擎和密码卸载只要根据不可信配置创建持久私有状态，后续复用就需要覆盖全部创建时输入的兼容契约。公开输出相等不能替代资源相等；把这份内部契约明确命名、集中失效，并用外部格式不变而私有需求变化的转换测试覆盖，才能把后端默认假设变成可审计的寿命保证。

故事结束时，从房间另一头看，第二幅画面和第一幅毫无区别：宽度没有变，颜色仍适配同一块屏幕，应用依旧称其为 720p。真正变化发生在门后。Chromium 现在会在画面跨入硬件前认出新工具集合，结束旧关系，抬起配置关卡，准备足够大的柜子。画面能够继续普通，正因为寿命决定终于完整。