Pixel 10 零点击攻击链：Project Zero 用 2 小时找到的 VPU 漏洞，揭示了 Android'纵深防御'的真实裂缝

引子：8 行 C 代码，让 Pixel 10 全失守

如果你想在一篇技术文章里看到"漏洞研究的圣杯（Holy Grail）“这种修辞，那它出自一位 Project Zero 研究员的笔下，多半是真的。

2026 年 5 月 13 日，Google Project Zero 的 Seth Jenkins 发布了《A 0-click exploit chain for the Pixel 10: When a Door Closes, a Window Opens》。这篇文章的核心结论冷峻而精确：

“Working in collaboration with Jann Horn, we spent 2 hours auditing this VPU driver and discovered an exceptional vulnerability.”

两小时审计，发现一个把整台 Pixel 10 从 zero-click 上下文一路拉到 root 的内核漏洞。

这个驱动来自 Chips&Media，是 Tensor G5 上的视频解码加速器 Wave677DV。漏洞代码极简——一个 mmap handler，8 行真正起作用的代码，但它把芯片的 MMIO 寄存器接口直接暴露给了 userspace。配合 Project Zero 之前披露过的 Dolby UDC 0-click 漏洞（CVE-2025-54957），整条链不需要用户点击任何东西、不需要诱导任何动作——只要你的手机能解码一段恶意 Dolby 音频，攻击者就能拿到 root。

这事比"又一个 Android 漏洞"严重得多，因为它揭示了三层结构性问题：

纵深防御（defense-in-depth）在 SoC 自研化时代正在失效——Pixel 用 RET PAC 替换 stack canary，听起来更先进，但实际只是把"上一关变难”，并没有切断攻击链。
SoC 厂商提供的加速器驱动是 Android 平台最薄弱的部分——上游 Linux 走 V4L2 框架，但厂商私有驱动经常 bypass 框架直接做 MMIO 映射。
Project Zero 的 2 小时 vs 厂商 SDLC 的几个月——攻防经济学已经彻底失衡。

本文拆解这条攻击链的技术细节，然后讨论一个更尖锐的问题：为什么"安卓系统级安全"这件事，在 2026 年比 2020 年更难？

一、攻击链结构：两步走到 root

先看整体结构：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
┌─────────────────────────────────────────────────────────────────┐
│           Pixel 10 完整 0-click 攻击链（2026-05）               │
├─────────────────────────────────────────────────────────────────┤
│                                                                 │
│  Step 1: Dolby UDC 0-click（CVE-2025-54957）                    │
│  ─────────────────────────────────────                          │
│  •  攻击面: libDolbyUDC.so —— 系统所有解码器都会调用              │
│  •  触发: 恶意 AC-4 / E-AC-3 音频流（彩信 / RCS / 网页自动播放）│
│  •  原语: 堆溢出，可控写到 dap_cpdp_init 函数指针                │
│  •  收益: 跳到 media codec 沙箱内的 shellcode                   │
│  •  上下文: mediacodec 用户、SELinux 沙箱                       │
│                                                                 │
│            ↓ 沙箱内执行                                          │
│                                                                 │
│  Step 2: VPU 驱动权限提升（新发现）                              │
│  ────────────────────────────────                                │
│  •  攻击面: /dev/vpu —— mediacodec selinux 域可访问              │
│  •  触发: mmap(/dev/vpu, ...)                                   │
│  •  Bug: vpu_mmap 把芯片 MMIO 物理地址直接映射给 userspace      │
│  •  原语: 任意物理内存读写（通过 MMIO 寄存器侧通道）             │
│  •  收益: 修改内核页表 / 提权到 root / 关 SELinux               │
│                                                                 │
└─────────────────────────────────────────────────────────────────┘

注意几个细节决定了这条链的"优雅程度"：

(1) 完全零交互。Dolby UDC 是 Android 媒体框架默认启用的解码器，几乎所有彩信/RCS 处理流程都会过它。Pixel 默认开 RCS，所以只要攻击者拿到你的手机号，就能发起攻击。

(2) 同一群人写的两个驱动。Project Zero 在文章里点名：“Based on the comments within the open-source C files, this driver is developed and maintained by the same set of developers who built the BigWave driver.” BigWave 是上一代漏洞集中地，这种"换个芯片型号但代码同一群人维护"的模式，是供应链安全的典型病灶。

(3) RET PAC 没救命。Project Zero 在 porting Dolby 漏洞时遇到一个"小麻烦"：Pixel 10 用 ARM 的 RET PAC（返回地址 PAC 签名）替换了传统的 -fstack-protector 栈金丝雀。RET PAC 的设计意图是阻止 ROP，但对覆盖函数指针的攻击场景毫无作用。研究员花了点时间，找到了 dap_cpdp_init（只在初始化时调用一次的函数指针），覆盖它即可——RET PAC 完全不在路径上。

二、那 8 行致命代码

我们直接看 Project Zero 在文章里贴出的源码（来自 Chips&Media 开源驱动，但 Pixel 实现略有修改）：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
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);
    /* This is a CSRs mapping, use 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;
}

这段代码做的事是：把 core->paddr（VPU 芯片的 MMIO 寄存器物理基址）映射到用户进程的虚拟地址空间。问题在 vm->vm_end - vm->vm_start 这个长度参数完全没有上界检查。

正常的内核驱动写 mmap 都要做三件事：

检查 offset 不超过设备 MMIO 区域大小
检查 length 不超过设备 MMIO 区域大小
对设备内存做 nocache 标记（这里 pgprot_device 做了）

这段代码只做了第 3 件。结果是：userspace 可以请求映射任意长度，从 paddr 开始往后映射 100MB、1GB、甚至整个物理地址空间。在 ARM64 设备上，物理地址空间是连续布局的，VPU 的 MMIO 区域旁边大概率就是其他外设或者 DRAM。

具体怎么利用？Project Zero 的思路（文章后半段描述）：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
1. mmap("/dev/vpu", length=huge_size) 
   → 用户得到一段虚拟地址，覆盖到 DRAM 区域

2. 通过这段地址直接读写物理 DRAM
   → 等于得到了 /dev/mem 的能力，但绕过了所有 LSM 检查

3. 定位内核页表 PGD
   → ARM64 的 TTBR1 在 DRAM 中位置较稳定，可通过 KASLR 泄露推断

4. 修改自己进程的 cred 结构 → uid=0, gid=0, capabilities=full
   → 完成 LPE

5. 修改 SELinux enforcing 标志位为 0
   → 关闭强制访问控制

6. 持久化（写入 vbmeta、boot 镜像等）

整个利用过程不需要任何额外的内核漏洞。一个 mmap，足以拿下整个内核。

三、Pixel 9 vs Pixel 10：纵深防御的"幻觉"

Project Zero 在文章标题里点了一个关键词：“When a Door Closes, a Window Opens”——上一扇门关上，另一扇窗打开了。这对应 Pixel 9 到 Pixel 10 的安全演进：

维度	Pixel 9	Pixel 10	攻击者视角
解码器栈	libDolbyUDC.so	libDolbyUDC.so (同一份)	漏洞 1:1 复用
栈保护	-fstack-protector	RET PAC	用函数指针覆盖即可绕
LPE 入口	BigWave 驱动	VPU (Wave677DV) 驱动	2 小时审计就找到
解码加速器	TPU + BigWave	TPU + VPU + GXP	攻击面更大
厂商	同一群开发者	同一群开发者	代码味道相同

这就是文章标题的悲凉之处：Google 投入大量资源加固，但只要 SoC 团队和驱动团队不发生根本变化，纵深防御只是把攻击链的步骤换了个样子。

更糟的是，Pixel 10 引入了更多加速器（VPU、GXP、ISP），每一个都是新的攻击面。Tensor G5 的 SoC 设计让 Android 拥有了"Pixel 独占"的 AI 性能，但同时也带来了"Pixel 独占"的攻击面。

四、为什么这事在 2026 年变得更严重？

不止 Pixel。2026 年第一季度，移动设备零日漏洞市场出现了几个显著变化：

(1) 商业监控团伙的"链可移植性"提高。NSO Group、Intellexa（这俩品牌已经多次改名）以及新冒头的 DarkSword（参见 Schneier 5 月的分析），都在批量投资"跨设备型号的链复用"——一条 Pixel 9 链改两小时就能跑在 Pixel 10 上，对他们的商业模式是巨大的利好。

(2) 上游 Android（AOSP）和 Pixel 内核的 diff 越来越大。Pixel 是 Google 的旗舰，但 Tensor 芯片让 Pixel 的内核驱动是"Pixel 独占"的——同样的 Android 版本，Pixel 10 上的内核代码 30%+ 是 GPU/VPU/TPU 厂商私有 fork。AOSP 的代码审计不能保护 Pixel。

(3) 商业 0-day 价格倒挂。2025 年 Zerodium 报价 Android 完整链是 250 万美元，iOS 是 200 万。2026 年 5 月 Operation Zero 等公司给出的暗盘价格里，Pixel 完整链已经超过 iPhone——因为 Pixel 用户更倾向于装 GrapheneOS 等加固系统，针对原版 Pixel 的链反而更稀缺、更有政府客户。

(4) Project Zero 团队的"反向使命"。Project Zero 内部的论调一直在变化。早期（2014-2018）是"找漏洞 → 给厂商 90 天 → 公开"。现在他们更愿意做的事是 写完整的攻击链 PoC 给厂商看，告诉对方"你的纵深防御一文不值"。Pixel 10 这篇就是典型——Project Zero 不只是说"有这么个 bug"，而是说"看，2 小时，root，你说的所有缓解措施都白搭"。

五、攻防经济学：2 小时 vs 几个月

让我们做一道残酷的算术题。

进攻侧投入：

1 名研究员 × 2 小时 audit
1 名研究员协作 × 2 小时
总计：~4 人时

防守侧投入：

厂商工程师 × ?月 = 编写驱动
Pixel 内核 maintainer × ?月 = 集成
Google Android Security Bulletin × 1 月 = 发现、patch、推送
OEM × 1-2 月 = 推到非 Pixel 设备
总计：~几千人时

进攻方 4 小时打穿，防守方至少 100x 的工程投入才能修复。这种经济学失衡的后果是什么？

是"纵深防御"作为话术的逐渐失去公信力。每一次厂商说"我们引入了 X 缓解措施"，Project Zero 就用 4 小时证明它可以被绕过。久而久之，安全社区会形成一种共识：只有移除攻击面（Attack Surface Reduction）有效，添加缓解措施基本没用。

GrapheneOS 已经是这条路线的代表。它的策略是：

默认禁用 USB（即使物理接入也无法访问）
禁用 SUPL（GPS 辅助协议，常见漏洞入口）
加固内存分配器（hardened_malloc）
严格限制 SELinux 域
不信任 OEM 私有驱动，能裁就裁

GrapheneOS 用户的设备在 Pixel 10 时代依然脆弱（VPU 驱动还在），但通过最小化攻击面，实际被打的概率显著降低。这是 Pixel 10 攻击链给整个移动安全行业的最大教训。

六、对普通用户：现在该做什么？

如果你用 Pixel：

2026-05 安全更新（SPL May 2026）是必装的。如果你的运营商版本没收到，去 Pixel 官网手动 sideload。
关掉 RCS 自动接收。或者至少关掉 RCS 在锁屏的预览。Dolby UDC 这种"无须用户交互"的攻击，RCS/MMS 是主要入口。
考虑 GrapheneOS。Pixel 系列继续是 GrapheneOS 唯一支持的硬件平台。如果你是高风险用户（记者、活动家、研究员），这不再是 paranoia 而是 baseline。

如果你不用 Pixel：

三星、小米、OPPO 同样有类似的私有驱动——只是没有 Project Zero 这种级别的研究团队公开针对它们的链。你的设备不安全 ≠ 没有同等的漏洞。
iOS 同样不能幸免。Schneier 同一周报道的 DarkSword 就是 iOS 全链。
真正的 Threat Model 选择题不是"哪个平台更安全"，而是 “哪个平台让我作为目标的成本最高”。

七、对开发者和系统设计者：5 条硬规则

如果你在写驱动或者 review 驱动代码：

任何 remap_pfn_range 调用都必须有 vm_end - vm_start 的上界检查。这是 Linux 内核驱动 review 第一行问题。Project Zero 这篇文章应该成为内核 mentor 的教材。
/dev/xxx 给 SELinux 域开放访问 = 你信任那个 SELinux 域里所有进程。mediacodec 沙箱不是可信沙箱，它是被设计来"反复被打"的。
加速器驱动应该走 V4L2 / drm_subsystem 等上游框架——这些框架的 ioctl 表都被审计过千百遍。绕过框架直接 expose 寄存器 = 主动放弃所有上游 review。
pgprot_device 不是安全保护，它只是缓存属性。一些 review 看到这行字会误以为"这段映射是 device-only safe"，错。
任何 OEM 驱动 fork 都需要内部安全 team 重新审计。“上游已经审计过” 不是免审金牌——Pixel 10 的 VPU 驱动正是因为是 fork，跳过了上游 V4L2 框架。

八、判断：移动平台安全的真正未来

我对未来 3-5 年移动平台安全的判断有三条：

(1) “纯软件加固"的边际收益归零。RET PAC、CFI、KASLR、SELinux 的加固空间已经被吃完了。下一波加固必须来自硬件（如 ARM 的 MTE，Memory Tagging Extension）和大幅 ASR（攻击面缩减）。Pixel 10 集成的 MTE 已经在 GrapheneOS 上默认启用——这是真正的护城河，但厂商出厂状态下 MTE 多数关闭以避免性能损失。

(2) SoC 自研化会让"Android 安全"分化成 N 个独立小生态。Pixel 的 Tensor、三星的 Exynos、小米的 Xring、OPPO 的 Mariana。每一个 SoC 都有自己的私有驱动、自己的攻击面、自己的补丁节奏。“Android 整体安全水位"这个概念会逐渐失去意义。

(3) Project Zero 这种"公开攻防教材"的价值会上升。每篇这种文章对厂商内部安全文化的拷打远胜过任何内部安全 review。未来 Apple、Samsung、Xiaomi 都会被迫公开自己的攻击链分析——这是被 Project Zero 倒逼的透明度。

对你的最后一句话：如果你在做高敏任务（无论是新闻、技术研究、还是企业 IT 负责人），请重新评估"我的手机能否被 root 而我不知情"这个问题。Pixel 10 这条攻击链的答案是：可以，而且只需要别人 4 个工时。

参考来源

Project Zero — A 0-click exploit chain for the Pixel 10: When a Door Closes, a Window Opens (Seth Jenkins, 2026-05-13)
Project Zero — On the Effectiveness of Mutational Grammar Fuzzing (Project Zero 系列)
CVE-2025-54957 — Dolby UDC heap overflow (NIST NVD)
Schneier on Security — DarkSword Malware (Bruce Schneier, 2026-05)
Android Security Bulletin — May 2026 (Google AOSP)
Chips&Media WAVE677DV 上游驱动 (开源参考)
GrapheneOS — Hardening compared to AOSP (GrapheneOS 文档)
ARM Architecture Reference Manual — Memory Tagging Extension (ARM 官方文档)

Jiayun's Blog