Pixel 10 的零点击利用链

# Pixel 10 的零点击漏洞利用链：一扇门关上，一扇窗打开 来源：https://projectzero.google/2026/05/pixel-10-exploit.html 我们最近发布了一个针对 Google Pixel 9 的[漏洞利用链](https://projectzero.google/2026/01/pixel-0-click-part-1.html)，证明了仅凭两个漏洞，就可以在 Android 上从零点击环境实现 root 权限。其中的 Dolby 零点击漏洞影响了所有 Android 设备，直到 2026 年 1 月被修复。虽然我们已经有了针对 Pixel 9 的漏洞利用链，但我们想知道是否也能为 Pixel 10 编写类似的漏洞利用链。 ## 更新 Dolby 漏洞利用 修改针对 CVE-2025-54957 的[漏洞利用](https://projectzero.google/2026/01/pixel-0-click-part-1.html)相对直接。大部分需要的更改涉及将 Pixel 9 上特定目标库版本计算的偏移量更新为 Pixel 10 库中的相应偏移量。唯一的挑战（除了希望我们当时能更好地记录哪些同步帧包含偏移量之外）是 Pixel 10 使用 RET PAC 取代了 `-fstack-protector`，这意味着 `__stack_chk_fail` 不再能被代码覆写。经过一些尝试后，我们使用了 `dap_cpdp_init`，这是一个初始化代码，可以在不引起功能问题的情况下被覆写，因为它只在解码器初始化时调用一次，之后不再使用。更新后的 Dolby UDC 漏洞利用可在[此处](https://project-zero.issues.chromium.org/428075495#attachment76717436)获取。此漏洞利用仅适用于未打补丁的设备（SPL 2025 年 12 月或更早版本）。 ## 移除 BigWave，引入 VPU 将漏洞利用链中的本地权限提升部分移植到 Pixel 10 是不可行的，因为该设备未搭载 BigWave 驱动。然而，在 mediacodec SELinux 上下文下的 /dev/vpu 中可以看到一个新驱动。该驱动用于与 Tensor G5 芯片上的 [Chips&Media Wave677DV](https://www.chipsnmedia.com/en/products/video.php) 硬件交互，旨在加速视频解码。根据开源 C 文件中的注释，该驱动由构建 BigWave 驱动的同一组开发人员开发和维护。与 Jann Horn 合作，我们花了 2 个小时审计这个 VPU 驱动，发现了一个特殊的漏洞。 与上游 Linux 驱动 WAVE521C（一个较旧的 Chips&Media 芯片）不同，Pixel 上用于 WAVE677DV 的驱动未与 V4L2（“Video for Linux API”）集成；相反，它直接将芯片的硬件接口暴露给用户空间，包括允许用户空间映射芯片的 MMIO 寄存器接口。该驱动主要建立设备内存映射、进行电源管理，并允许用户空间等待来自芯片的中断。 ## 内核漏洞的圣杯 这个[特定的漏洞](https://project-zero.issues.chromium.org/issues/463438263)引起了我们的注意，因为它异常易于利用： ```c static int vpu_mmap(struct file *fp, struct vm_area_struct *vm) { unsigned long pfn; struct vpu_core *core = container_of(fp->f_inode->i_cdev, struct vpu_core, cdev); vm_flags_set(vm, VM_IO | VM_DONTEXPAND | VM_DONTDUMP); /* 这是 CSR 映射，使用 pgprot_device */ vm->vm_page_prot = pgprot_device(vm->vm_page_prot); pfn = core->paddr >> PAGE_SHIFT; return remap_pfn_range(vm, vm->vm_start, pfn, vm->vm_end-vm->vm_start, vm->vm_page_prot) ? -EAGAIN : 0; } ``` 这个 mmap 处理程序旨在用于将 VPU 硬件的 MMIO 寄存器区域映射到用户态虚拟地址空间——该区域包含在某个物理内存地址范围内。在这样做时，它完全基于 VMA 的大小调用 remap_pfn_range，而完全没有限制到该寄存器区域的大小。这意味着，通过在 mmap 系统调用中指定一个大于寄存器区域的大小，调用者可以从 VPU 寄存器区域的物理地址开始，将任意多的物理内存映射到用户空间。内核镜像的全部内容（包括 .text 和 .data 区域）位于比 VPU 寄存器区域更高的物理地址，因此可以通过这个漏洞被用户空间访问和修改。 此时，只需覆写任意内核函数即可获得内核代码执行权限——或者任何想要的基元。这一点更加容易，因为 Pixel 上的[内核总是在相同的物理地址](https://projectzero.google/2025/11/defeating-kaslr-by-doing-nothing-at-all.html)，所以 VPU 内存区域与内核之间的偏移量始终是一个已知值。因此，甚至不需要在映射的物理内存中扫描内核——只要使 VMA 长度足够大，你就能确切知道它相对于 mmap 返回地址的位置。 用这个漏洞实现对内核的任意读写只需要 5 行代码，而编写完整的漏洞利用程序用了不到一天的时间。 ## 补丁过程 我在 2025 年 11 月 24 日报告了这个漏洞，Android VRP 将该问题评为*严重*级别。这是一个进步，因为我们用于 Pixel 9 权限提升的 BigWave 漏洞（具有相同的安全影响）最初被评为*中等*严重级别。这代表了在对这类漏洞进行分类和修复方面的态度发生了有意义且积极的变化。该漏洞在最初报告后的 71 天内，即 2 月份的 Pixel 安全公告中被修复。考虑到这是我报告的 Android 驱动漏洞中，第一次在供应商得知漏洞后的 90 天内被修复，这个速度非常快。 ## 结论 从这项研究中可以得出正反两方面的结论。Project Zero 的一个关键目标是推动超出单个漏洞修复的系统性改进，影响更好的开发流程和更健壮的代码库，从而为用户带来安全性的提升。对 VPU 漏洞的处理展示了 Android 分类流程的明显进步，因为该漏洞的初始修复时间比之前的 BigWave 问题短得多。Android 努力确保严重漏洞得到有效修复，这将有助于保护许多 Android 设备。 与此同时，这个案例突显了 Android 驱动程序中持续需要更全面健壮和安全感知的代码。当我报告 BigWave 中的漏洞时，我希望促使它的开发者评估他们的其他驱动是否存在明显的安全问题，但 5 个月后，我们仍然在他们的 VPU 驱动中发现了一个严重且极其浅显的漏洞，即使粗略地审计代码库也能立刻注意到。加强驱动安全仍然是确保 Android 生态系统安全的关键优先事项，我们继续强烈鼓励供应商改进软件开发实践，主动努力防止这类漏洞最终到达用户手中。 安全报告经常揭示产品团队遗漏的复杂问题，但重要的是，软件供应商必须采取必要措施，确保软件产品，尤其是安全关键型产品，在发布时处于合理无漏洞的状态，并且软件团队应采取积极主动的方法处理软件安全、代码审计和漏洞修补。