A 0-click exploit chain for the Pixel 10: When a Door Closes, a Window Opens¶

Ch12.042 A 0-click exploit chain for the Pixel 10: When a Door Closes, a Window Opens¶

📊 Level ⭐⭐ | 9.0KB | entities/a-0-click-exploit-chain-for-the-pixel-10-when-a-door-closes-a-window-opens.md

核心要点¶

Project Zero 团队成功为 Pixel 10 编写了类似 Pixel 9 的 0-click exploit chain
两个漏洞构成完整攻击链：Dolby UDC（媒体解码器漏洞）+ VPU 驱动漏洞
Pixel 9 的 BigWave 驱动在 Pixel 10 中不存在，取而代之的是 VPU 驱动
VPU mmap 处理程序存在严重安全漏洞：可以通过指定大于寄存器区域的 size 来映射任意物理内存
5 行代码实现任意内核读写；完整 exploit 不到一天完成
漏洞修复时间：71 天（2025 年 11 月 24 日报告，2026 年 2 月补丁）

漏洞链概述¶

零点击上下文 → Dolby UDC 漏洞 → 代码执行
                              ↓
                     VPU mmap 漏洞 → 内核任意读写

Dolby UDC 漏洞（CVE-2025-54957）¶

修改用于 Pixel 9 的 exploit 相对简单，主要涉及更新特定库版本的偏移量。Pixel 10 使用 RET PAC 代替 -fstack-protector，意味着 __stack_chk_fail 不可覆盖。最终使用 dap_cpcp_init（初始化代码）替代。

VPU 驱动漏洞¶

关键漏洞代码：

static int vpu_mmap(struct file *fp, struct vm_area_struct *vm)
{
    unsigned long pfn;
    struct vpu_core *core = container_of(...);
    vm_flags_set(vm, VM_IO | VM_DONTEXPAND | VM_DONTDUMP);
    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 handler 根据 VMA 大小而非寄存器区域实际大小调用 remap_pfn_range。通过指定大于寄存器区域的 size，调用者可以从 VPU 寄存器区域开始映射任意物理内存。由于 Pixel 上内核始终位于相同物理地址（已知偏移），攻击者可以直接计算内核位置，无需扫描。

修复过程¶

报告时间：2025 年 11 月 24 日
评级：High severity（相比 BigWave 漏洞被评为 Moderate 是明显进步）
修复时间：71 天
发布渠道：2026 年 2 月 Pixel 安全公告

深度分析¶

从 Pixel 9 到 Pixel 10 的 exploit 移植挑战¶

移植过程揭示了几个重要观察： 1. OEM 特定驱动的脆弱性：BigWave 驱动是 Pixel 9 特有的，在 Pixel 10 中不存在。每个 OEM 都有自己定制的驱动栈，这带来了独特的攻击面。 2. 同类驱动的继承关系：VPU 驱动由构建 BigWave 驱动的同一组开发者开发，这说明驱动安全问题可能在同一开发团队的多个产品中重复出现。 3. PAC 的绕过：Pixel 10 使用 RET PAC（指针认证码）代替传统的栈保护符。这改变了 exploit 策略，需要找到不依赖覆盖 __stack_chk_fail 的利用路径。

VPU mmap 漏洞的技术深度¶

这个漏洞属于"内核直接任意读写"类，是特权升级的终极目标。几个关键点： 1. 错误边界检查：mmap handler 错误地信任用户提供的 VMA 大小，而没有验证它是否在硬件寄存器区域的边界内。 2. 物理地址连续性：VPU 寄存器区域和内核镜像的物理地址在 Pixel 上是可预测的。这意味着偏移量是固定的，不需要信息泄露。 3. 利用简单性：实现任意内核读写的 exploit 只需要 5 行代码。这不是复杂的ROP链或喷射技术，只是正确使用 mmap 系统调用。

补丁时间的意义¶

71 天的修复时间对于内核驱动漏洞来说是相当快的。Project Zero 指出这是他们报告的第一个在 90 天内修复的 Android 驱动漏洞。这反映了 Android 安全响应流程的改进：

初始评级从 Moderate 升为 High
修复时间显著缩短
漏洞赏金和公开披露政策推动更快的响应

系统性改进 vs 单个漏洞修复¶

Project Zero 的核心目标是推动系统性改进，而非仅仅修复单个 bug。他们希望看到：

更强的代码安全开发实践
供应商主动审计自己的其他驱动
发布前更全面的安全测试然而，5 个月后在 VPU 驱动中仍然发现了"浅显且立即可发现"的严重漏洞，说明这些愿望尚未实现。

实践启示¶

1. OEM 特定驱动是重要的攻击面¶

Pixel 10 上 BigWave 的缺失和 VPU 的出现说明：OEM 定制驱动带来独特的攻击面。这些驱动通常：

代码审查较少
安全测试不如主线内核严格
由较小的团队开发，可能缺乏安全编码经验建议：在评估设备安全性时，OEM 定制驱动的数量和质量是重要指标。

2. 驱动安全应该是系统性优先级¶

单个漏洞的快速修复固然好，但系统性改进更重要：

驱动开发者应该交叉审计团队开发的其他驱动
代码审查应该包含安全边界检查
新的驱动应该接受基本的安全审计

3. mmap 权限检查的关键性¶

VPU mmap 漏洞的本质是缺少边界检查。这提醒我们：

任何映射物理设备的 mmap handler 必须验证请求的大小不超过设备寄存器区域
用户控制的 size 参数必须与硬件限制进行交叉验证
默认 deny 的安全原则：没有明确允许的都是禁止的

4. 物理地址可预测性的危险¶

Pixel 上内核物理地址的稳定性是一个已知的安全风险（Project Zero 2025年11月的博客讨论过）。虽然这简化了 exploit 开发，但也说明：

KASLR 在物理地址层面无效
硬件驱动的内存映射区域可能与内核物理地址重叠
IOMMU 可能提供了一些保护，但不是银弹

5. 安全研究对生态的贡献¶

Project Zero 的工作展示了安全研究的价值：

发现漏洞后与供应商协调修复
推动系统性安全改进
公开研究成果让整个生态系统受益但关键是：供应商需要采取主动行动，而不是仅仅修复报告的单个漏洞。