当前位置：首页 > news >正文

Google Pixel 10零点击漏洞链深度解析：5行代码拿下内核的技术细节与行业反思

news 2026/7/22 4:45:51

一、引言

2026年5月13日，Google Project Zero（GPZ）团队发布了一篇震惊安全界的博文，披露了针对Google Pixel 10手机的完整零点击利用链。这条利用链只需向目标设备发送一条恶意Dolby Digital Plus（DD+）音频消息，无需用户进行任何点击或交互操作，即可实现从远程代码执行（RCE）到内核任意读写，最终完全控制整个设备。

更令人担忧的是，整个利用链的开发过程异常简单：研究人员仅用2小时就发现了关键的VPU驱动漏洞，5行代码即可实现内核任意读写，完整利用代码在不到一天的时间内就完成了编写。这一事件再次暴露了移动设备安全体系中的深层次问题，特别是第三方硬件驱动和多媒体预解析机制带来的巨大攻击面。

本文将从技术角度深入解析这条零点击漏洞链的每一个环节，展示完整的漏洞利用代码，分析其背后的安全设计缺陷，并探讨这一事件对整个移动安全行业的启示。

二、事件速览

2.1 基本信息

披露时间：2026年5月13日（GPZ官方博文）
研究人员：Seth Jenkins与Jann Horn（Google Project Zero）
影响机型：Google Pixel 10系列（搭载Tensor G5芯片）
漏洞组合：
- CVE-2025-54957：Dolby Unified Decoder（UDC）整数溢出导致远程代码执行
- 未分配CVE：Tensor G5 VPU驱动mmap边界校验缺失导致本地提权
修复状态：
- Dolby漏洞：2026年1月Android安全补丁修复
- VPU驱动漏洞：2026年2月Pixel安全补丁修复

2.2 完整时间线

时间	事件
2025年11月24日	GPZ向Google上报VPU驱动漏洞
2025年12月	Google开始内部开发补丁
2026年1月5日	Android安全补丁修复Dolby漏洞（CVE-2025-54957）
2026年2月5日	Pixel安全补丁修复VPU驱动漏洞
2026年5月13日	GPZ公开完整利用链及技术细节

三、完整攻击链技术解析

3.1 攻击链总览

整个攻击过程分为两个独立但紧密衔接的阶段，如下图所示：

3.2 第一阶段：零点击入口——Dolby解码器远程代码执行（CVE-2025-54957）

3.2.1 漏洞原理

CVE-2025-54957是一个存在于Dolby Unified Decoder（UDC）库中的整数溢出漏洞，影响版本从v4.5到v4.13。当解码器处理精心构造的DD+音频比特流中的"evolution data"字段时，会错误地计算数据包大小，导致堆缓冲区溢出，进而引发越界写操作。

这个漏洞的特别之处在于它的零点击特性。在Google Messages应用中，为了提供语音消息转写功能，系统会在用户收到消息后自动对音频内容进行预处理和解码。这意味着恶意音频文件只要成功发送到目标设备，就会在用户完全不知情的情况下触发漏洞。

3.2.2 RET PAC绕过技术

Pixel 10相比前代产品引入了一项重要的安全增强：使用**返回地址指针认证（RET PAC）**替代了传统的栈保护机制（-fstack-protector）。这一变化使得之前在Pixel 9上使用的覆盖__stack_chk_fail函数的利用方法完全失效。

为了绕过RET PAC保护，研究人员采用了一种巧妙的策略：他们不再尝试覆盖栈保护函数，而是转而覆盖一个名为dap_cpdp_init的初始化函数。这个函数具有以下两个关键特性：

它只在解码器初始化时被调用一次
一旦初始化完成，覆盖它的代码不会影响解码器的正常运行

通过覆盖这个函数的入口点，研究人员成功地在不触发任何安全检查的情况下获取了对程序控制流的完全掌控。

3.2.3 沙箱限制

成功利用Dolby漏洞后，攻击者获得的代码执行权限受到Android系统的严格限制。具体来说，代码运行在mediacodec沙箱上下文中，只能访问有限的系统资源和设备文件。这就是为什么需要第二个漏洞来进行本地提权。

3.3 第二阶段：本地提权——Tensor G5 VPU驱动mmap边界校验缺失

3.3.1 漏洞发现过程

在Pixel 9上，研究人员使用BigWave AV1解码驱动漏洞来进行本地提权。然而，Pixel 10不再搭载BigWave驱动，而是引入了一个全新的VPU驱动来与Tensor G5芯片上的Chips&Media Wave677DV视频处理单元交互。

有趣的是，这个新的VPU驱动是由与开发BigWave驱动相同的团队维护的。基于这一信息，研究人员决定对这个新驱动进行审计。令人震惊的是，他们仅用了2小时就发现了一个极其严重的漏洞。

3.3.2 漏洞原理

这个VPU驱动没有采用标准的Linux V4L2（Video for Linux API）接口，而是直接将硬件接口暴露给用户态，包括允许用户态映射芯片的MMIO寄存器区域。

漏洞出现在驱动的vpu_mmap函数中。这个函数的设计目的是将VPU硬件的MMIO寄存器区域映射到用户态虚拟地址空间。然而，它在实现时存在一个根本性的逻辑错误：它完全根据用户提供的虚拟内存区域（VMA）大小来调用remap_pfn_range函数，而没有对映射的大小进行任何边界检查，以确保它不会超出VPU寄存器区域本身的大小。

以下是完整的漏洞代码：

staticintvpu_mmap(structfile*fp,structvm_area_struct*vm){unsignedlongpfn;structvpu_core*core=container_of(fp->f_inode->i_cdev,structvpu_core,cdev);vm_flags_set(vm,VM_IO|VM_DONTEXPAND|VM_DONTDUMP);vm->vm_page_prot=pgprot_noncached(vm->vm_page_prot);pfn=core->res.start>>PAGE_SHIFT;// 漏洞所在：没有检查vm->vm_end - vm->vm_start是否超过VPU寄存器区域大小returnremap_pfn_range(vm,vm->vm_start,pfn,vm->vm_end-vm->vm_start,vm->vm_page_prot)?-EAGAIN:0;}

这个简单的错误导致了灾难性的后果：攻击者可以通过指定一个大于VPU寄存器区域大小的映射请求，将任意数量的物理内存映射到用户态，包括整个内核镜像。

3.3.3 5行代码实现内核任意读写

更糟糕的是，在Pixel设备上，内核总是被加载到固定的物理地址上。这意味着攻击者不需要进行任何复杂的内存扫描或KASLR（内核地址空间布局随机化）绕过，只需要通过一个固定的偏移量就可以直接计算出内核在映射内存中的位置。

以下是实现内核任意读写的完整代码，仅需5行：

#include<fcntl.h>#include<sys/mman.h>#include<stdint.h>intmain(){// 打开VPU设备文件intfd=open("/dev/vpu",O_RDWR);// 映射4GB物理内存到用户态void*addr=mmap(0,0x100000000,PROT_READ|PROT_WRITE,MAP_SHARED,fd,0);// Pixel 10内核物理基地址固定为0x80010000// VPU寄存器区域物理基地址为0x1a000000// 计算内核在映射内存中的虚拟地址uint64_tkernel_base=(uint64_t)addr+(0x80010000-0x1a000000);// 内核任意写示例：修改内核数据*(uint64_t*)(kernel_base+0x5678)=0xdeadbeef;// 内核任意读示例：读取内核数据uint64_tvalue=*(uint64_t*)(kernel_base+0x1234);return0;}

这段代码的工作原理非常简单：

打开/dev/vpu设备文件
调用mmap函数请求映射4GB的物理内存
由于VPU寄存器区域的物理基地址是0x1a000000，而内核的物理基地址是0x80010000，因此内核在映射内存中的偏移量就是0x80010000 - 0x1a000000
通过这个偏移量，攻击者可以直接读写内核内存中的任意位置

3.3.4 提权与持久化

获得内核任意读写权限后，攻击者可以轻松地提升自己的权限到root级别。最常见的方法是覆盖内核中的commit_creds函数，将当前进程的凭据替换为root用户的凭据。

此外，攻击者还可以修改内核中的其他关键数据结构，关闭SELinux保护，安装后门程序，实现对设备的持久化控制。

四、修复方案与补丁分析

4.1 Dolby漏洞修复

Dolby公司在2025年10月发布了安全公告，修复了CVE-2025-54957漏洞。修复方案主要是在处理DD+比特流中的"evolution data"字段时，增加了对数据包大小的正确验证，防止整数溢出的发生。

4.2 VPU驱动漏洞修复

Google在2026年2月的Pixel安全补丁中修复了VPU驱动漏洞。修复方案非常直接：在vpu_mmap函数中增加了对映射大小的边界检查，确保映射不会超出VPU寄存器区域的大小。

以下是修复后的代码：

staticintvpu_mmap(structfile*fp,structvm_area_struct*vm){unsignedlongpfn;unsignedlongsize;structvpu_core*core=container_of(fp->f_inode->i_cdev,structvpu_core,cdev);vm_flags_set(vm,VM_IO|VM_DONTEXPAND|VM_DONTDUMP);vm->vm_page_prot=pgprot_noncached(vm->vm_page_prot);pfn=core->res.start>>PAGE_SHIFT;size=vm->vm_end-vm->vm_start;// 修复：增加边界检查if(size>resource_size(&core->res))return-EINVAL;returnremap_pfn_range(vm,vm->vm_start,pfn,size,vm->vm_page_prot)?-EAGAIN:0;}