车载IOMMU多段映射整数溢出漏洞（CVE-2026-82049）深度解析

一、漏洞背景与车载 IOMMU 的安全定位

在新一代智能座舱与域控制器架构中，IOMMU（输入输出内存管理单元）承担着硬件级安全隔离的核心角色。以高通 SA8295、SA8775 为代表的车规 SoC，普遍依赖 IOMMU 完成 DMA 外设地址翻译与权限隔离，将 GPU、多媒体编解码器、车载以太网、CAN 控制器、MIPI 摄像头等大量具备 DMA 能力的外设限制在预设的 IOVA（IO 虚拟地址）窗口内，防止它们越权访问内核内存与安全域。

为了提升大吞吐量场景下的映射效率，高端车规 SoC 的 IOMMU 驱动普遍引入了多段连续映射能力：调用者可以一次性提交多段物理内存片段，由内核合并为一段连续的 IOVA 地址空间，供 DMA 外设使用。CVE-2026-82049 正是出现在这条性能优化路径上——多段长度累加时缺少整数溢出校验，导致映射边界判定失效，最终形成 DMA 越界写入能力。

这个漏洞属于典型的“校验粒度不匹配”缺陷：单段长度均通过了合法性校验，但多段累加后的总长度发生无符号整数回绕，使最终映射区间远小于实际 DMA 可访问范围。常规的单维度边界检查根本无法拦截这类攻击。

二、漏洞核心原理：多段累加的整数溢出陷阱

2.1 多段 IOVA 映射的正常逻辑

IOMMU 多段映射的标准流程如下：

1. 调用者提交 seg_num 个分段描述符，每个分段包含物理基址、IOVA 起始地址、段长度；
2. 内核遍历所有分段，累加计算总映射长度；
3. 校验总长度是否超出设备允许的 IOVA 寻址范围；
4. 校验通过后，为所有分段建立连续的页表映射。

漏洞触发点位于总长度累加环节：内核使用 64 位无符号整数累加各段 seg_size 时，没有做加法溢出判断。如果构造 8 段长度为 0x2000000000000000 的合法分段，累加后总长度会发生 u64 回绕，最终计算出的总长度远小于单段长度——边界校验自然就被轻易绕过。

2.2 越界写入的形成机制

由于总长度校验以回绕后的错误值为基准，内核只会为这个“名义总长度”建立页表映射，但外设侧依然可以按照完整的分段地址范围发起 DMA 读写。此时 DMA 传输会越过合法映射边界，直接写入未被授权的物理内存区域，覆盖内核 slab 对象、页表结构乃至函数指针。

与传统单段长度超限漏洞相比，这个漏洞的隐蔽性极强：

• 单段长度均落在驱动允许的合法区间内，静态规则扫描和灰度测试极易漏过；
• 溢出发生在累加环节，属于逻辑层缺陷，而非简单的参数校验缺失；
• 攻击载荷分散在多个分段之中，特征不明显，难以通过流量监控与调用审计发现。

三、车规 SoC 场景的危害放大效应

通用服务器场景中，IOMMU 漏洞往往需要配合特定 PCIe 设备才能触发，利用门槛较高。但在车载域控架构下，它的危害被显著放大：

DMA 外设密度高。 座舱域控集成 GPU、VPU、DSP、CAN 控制器、以太网 MAC、USB 控制器、摄像头 ISP 等十余类具备 DMA 能力的外设，可用于触发越界写入的入口远多于通用平台。其中 udmabuf、多媒体共享缓冲区等接口更是直接向用户态开放了部分 DMA 配置能力。

安全隔离防线被击穿。 IOMMU是pKVM虚拟化、TEE周边隔离、外设沙箱的底层依赖。一旦 IOMMU 边界失效，攻击者就可以通过 DMA 直接写入 Host 内核内存，突破虚拟化域隔离，实现从座舱域到仪表域、网关域的横向渗透。

持久化与供应链风险。 利用 DMA 越界写入能力，攻击者可以篡改固件加载逻辑、修改安全启动校验参数，配合 OTA 链路实现持久化植入。如果漏洞存在于 BSP 厂商的通用驱动中，将影响同平台多款车型，形成批量风险。

四、漏洞利用链推演与前置条件

4.1 完整利用路径

1. 初始权限获取：通过座舱应用层漏洞、蓝牙近场漏洞或调试接口，获取普通用户权限与 DMA 设备操作能力；
2. 构造多段映射请求：向 IOMMU 驱动提交多段 IOVA 映射参数，使总长度累加溢出，绕过边界校验；
3. 触发 DMA 越界写入：控制外设发起 DMA 传输，向越界内存区域写入可控数据，覆盖内核中目标 slab 对象；
4. 控制流劫持：篡改函数指针、中断描述符或任务结构体，劫持内核执行流，完成本地提权；
5. 域内横向：如果处于虚拟化 Guest 中，还可以进一步突破 pKVM 隔离，接管 Host 内核与整车虚拟化平台。

4.2 前置约束

该漏洞虽然危害等级为 T1，但存在明确的利用门槛：

• 需要能够访问 IOMMU 映射接口或持有可控 DMA 设备句柄；
• 车机量产固件通常会收紧设备节点权限，普通应用无法直接操作 IOMMU 字符设备；
• 不同厂商的 IOMMU 驱动 IOCTL 定义、分段数量上限存在差异，利用代码不具备通用性。

五、缓解与修复方案

5.1 内核驱动层修复

• 累加环节增加溢出校验：在多段长度求和时使用饱和加法，或在累加后校验 total < seg_size 的回绕特征，一旦检测到溢出直接拒绝请求；
• 双重边界校验：除总长度校验外，对每一段的结束地址单独校验，确保所有分段均落在合法 IOVA 范围内；
• 页表映射兜底：建立映射时以单段结束地址为边界再次核对，避免逻辑层错误传导到硬件页表。

5.2 车载工程化加固

• 接口权限收敛：量产固件中关闭用户态直接 IOMMU 映射接口，DMA 配置统一由可信服务代理完成；
• 设备分组隔离：将不同安全等级的外设划分到不同 IOMMU 域，限制单个域的寻址范围；
• DMA 访问监控：开启 IOMMU 硬件错误中断，对越界 DMA 访问进行实时拦截与告警；
• 关闭非必要特性：如果业务不需要多段连续映射，可以在内核配置中禁用该特性，从攻击面层面消除风险。

六、总结

CVE-2026-82049 是典型的“性能优化引入安全缺陷”案例。为了提升 DMA 吞吐而引入的多段映射机制，因为一处加法溢出校验缺失，击穿了 IOMMU 这道硬件级安全防线。对于智能汽车这类高安全等级场景，底层驱动的每一处性能改造都需要伴随同等强度的安全审计——尤其是边界校验、整数运算、内存管理等核心逻辑。任何粒度不匹配的校验都可能成为整车安全的溃堤之穴。

随着车载域控向多域融合、全虚拟化方向演进，IOMMU、SMMU 这类硬件隔离单元的安全权重将持续提升。从 BSP 供应链层面规范驱动安全编码标准、建立整数运算与边界校验的强制审计规则，是应对这类底层漏洞的根本解法。