研究者在FFmpeg项目的问题跟踪系统里公开了一个新缺陷。模糊测试工具在索尼PS2音频格式VPK的解封装器libavformat/vpk.c里,找到了一个整数除零问题。构造一个21字节、声道数被设成0的畸形头部,就能让读取这个文件的FFmpeg程序在处理最后一块数据时触发SIGFPE,直接崩溃。
这不是能远程执行代码的高危漏洞。材料里也没有内存越界读写或释放后使用的迹象。它能稳定造成拒绝服务,但更值得注意的是:头部解析阶段明明检查过声道数,程序跑到包读取阶段时,这个检查为什么没有兜住。
头部查过一次,运行时又崩了一次
出问题的函数是vpk_read_packet。处理流的最后一个数据块时,它把vpk->last_block_size除以par->ch_layout.nb_channels,紧跟着又用同一个除数算skip。只要nb_channels是0,这两次除法都会让CPU抛出除零异常。
按设计,这个值不该是0。vpk_read_header解析24字节头部时,确实会检查声道数必须大于0。研究者给出的触发链显示,问题出在模糊测试所用的自定义AVIO读取路径:探针阶段和头部解析阶段读到的声道数是合法值,但程序真正跑到vpk_read_packet时,这个值又变回了0。
也就是说,头部检查和包读取时的状态,不是同一次判断的结果。中间这段路径上声道数被谁改动、为什么改动,材料没有交代清楚——这正是"检查过、又没检查住"这类缺陷最难查的地方。
这类问题和内存破坏类漏洞不是一回事,危害上限也不一样:
| 维度 | 本次VPK除零缺陷 | 典型内存破坏漏洞(越界读写/UAF) |
|---|---|---|
| 触发结果 | 确定性拒绝服务(SIGFPE崩溃) | 可能拒绝服务,也可能内存泄漏或代码执行 |
| 触发条件 | 需进入VPK解封装,且经过特定AVIO路径 | 因漏洞而异,路径不固定 |
| 目前证据支持的危害上限 | 拒绝服务 | 部分历史案例可升级到远程代码执行 |
普通用户手动打开一个正常的VPK音频文件,基本不会撞上这个问题——正常头部里声道数不会是0。
风险边界要说清楚:这条触发链依赖模糊测试器的自定义AVIO读取方式。常规文件打开路径是否同样能复现,材料没有给出证据,需要单独核验。
谁该现在就检查自己的FFmpeg调用链
真正会撞上这个缺陷的,是让FFmpeg解析不可信来源文件的系统。转码服务、内容审核流水线、媒体解析中台,只要调用avformat_open_input加av_read_frame处理外部上传文件,且格式探测认定某个文件是VPK,就有被这21字节打崩的可能。
| 读者群体 | 暴露条件 | 现在能做什么 |
|---|---|---|
| 处理用户上传/外部媒体的开发者与安全团队 | 允许FFmpeg自动探测格式,没有限制可解析的容器类型 | 检查解析入口是否放行VPK探测;给解封装环节加格式白名单;捕获或隔离SIGFPE,避免单个畸形文件打崩整个进程 |
| 维护转码、审核、媒体解析基础设施的团队 | 服务端批量调用avformat_open_input+av_read_frame处理外部文件 | 补丁合并前用沙箱或独立子进程跑解封装逻辑;配置崩溃自动重启和告警,防止一个文件拖垮整个服务节点 |
这两类人现在能做的事,不是等安全公告。先把VPK这类冷门格式从自动探测名单里挪出去,或者给解封装进程加一层隔离,比等版本号更现实。
接下来该盯什么
研究者给出的修复方案很直接:在vpk_read_packet开头再加一道声道数检查,等于零就返回AVERROR_INVALIDDATA,和vpk_read_header里已有的校验逻辑保持一致。
但目前这只是issue里的建议代码。材料没有显示它已经被合并进代码库,也没有对应的版本号或安全公告。
接下来值得盯的是三件事:补丁是否合入主线、是否分配CVE编号、常规文件打开路径(不经过自定义AVIO)是否同样能触发。这些问题有答案之前,"升级到哪个版本能修复"本身还没有答案。
VPK这种冷门老平台专用格式,调用量小,审查天然比mp4、mkv这类主流容器松。这次除零缺陷更像是提醒所有处理不可信媒体输入的系统:该假设每个冷门解封装器背后都可能藏着类似的状态校验缝隙,而不是等公告发出来才去查。