Google Project Zeroが、Pixel 10で使える0-click exploit chainを公開しました。
0-clickというのは、名前の通り被害者が何も操作しなくても成立する攻撃のことです。たとえば怪しいリンクを開かせる必要すらなく、メッセージやデータの受信だけで攻撃が始まるタイプです。
正直、これはかなり怖いです。スマホの攻撃の中でも、かなり“イヤなやつ”だと思います。
今回の話は、ざっくり言うとこうです。
しかも、このVPUドライバの欠陥はかなり単純で、監査したらすぐ見つかるレベルだったと書かれています。
ここは率直に言って、「そんな基本的な見落としが残っていたのか」と驚きました。高度なゼロデイというより、コードの安全確認が足りていなかったことが透けて見えるタイプの問題です。
Project Zeroは以前、Pixel 9向けのexploit chainを公開していて、それは「0-clickからrootまでを2つの脆弱性でつなぐ」ものでした。
その起点になっていたのが、Dolbyの脆弱性です。Dolbyは音声や動画の処理に関わることが多い名前ですが、今回の文脈ではメディア処理ライブラリの欠陥として登場します。
Pixel 10でも似た攻撃を作れるか試したところ、基本的にはオフセットの調整で対応できたそうです。
オフセットというのは、メモリ上の「何バイトずれた位置に何があるか」という情報です。プログラムやライブラリの版本が変わると、この位置が少しずつズレるので、攻撃コードも合わせて直す必要があります。
ただしPixel 10では、**-fstack-protector** の代わりに RET PAC が使われていて、以前のように __stack_chk_fail を上書きする方法が使えなかったとのこと。
ここは少し専門的ですが、要するに「従来の壊し方が塞がれていた」という話です。そこで別の関数、dap_cpdp_init を書き換える方法に切り替えています。
こういう「扉が閉まったら、別の窓を探す」感じ、いかにも攻撃研究らしくて面白いです。もちろん面白がっていい話ではないのですが、技術としての執念はすごい。
なお、この更新版のDolby exploitは未修正端末でのみ動作し、SPL December 2025 or earlier と書かれています。つまり、2025年12月時点のセキュリティパッチより古い端末が対象です。
Pixel 9で使ったローカル権限昇格のつなぎ目、つまりBigWave driver はPixel 10には載っていませんでした。
そのため、同じ経路は使えません。
そこで新たに見つかったのが、**/dev/vpu** というデバイスです。これは Tensor G5 の Chips&Media Wave677DV というシリコンを動画デコード用に使うためのドライバです。
簡単に言うと、動画を速く処理するためのハードウェアを、Androidの中から操作する窓口です。
Project ZeroはJann Hornと協力して、このVPUドライバを2時間監査したところ、かなり露骨な脆弱性を見つけたとしています。
2時間で致命傷を見つけるのは、正直、ドライバの側にかなりまずい匂いがあったのだろうと思います。
記事の中心は、このコードです。
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;
}
ここで重要なのは、mmap という仕組みです。
mmap は、デバイスやファイルの中身をメモリのように見せるための仕組みです。うまく使うと便利ですが、実装を誤ると危険です。
このコードでは、remap_pfn_range を使って VPUのレジスタ領域 をユーザー空間にマップしています。
しかし問題は、マップするサイズをVMAの長さだけで決めていて、実際のレジスタ領域の大きさで制限していないことです。
これが何を意味するかというと、
ユーザーが mmap のサイズを大きく指定すると、VPUの領域の先にある物理メモリまでずっと見えてしまうのです。
しかもPixelでは、kernelが常に同じ物理アドレスにあるため、VPU領域からkernelまでの距離も毎回分かっています。
つまり、どこにkernelがあるかを探す必要すらない。
「この位置から何バイト先がkernel」と最初から分かっているので、そのまま読んだり書いたりできる、というわけです。
これはかなり派手です。kernelメモリに対するarbitrary read-write、つまり自由な読み書きができてしまえば、実質かなり勝ちに近いです。
Project Zeroによると、この脆弱性を使ってkernelに対する読み書きの原始的な能力を得るのに必要だったコードは、たった5行だったそうです。
さらに、フルエクスプロイトの作成も1日未満で済んだとのこと。
ここは、技術的にはすごく面白い一方で、セキュリティ上はかなり危険な匂いがします。
攻撃が難しいからこそ防御の余地があるのですが、こういう「低労力で致命傷」に近い欠陥は、攻撃者にとって非常に都合がいいです。
この脆弱性は、2025年11月24日に報告され、Android VRPではHigh severity と評価されました。
Pixel 9のBigWave問題が当初 Moderate だったことを考えると、今回はより重く扱われたのは前進だと記事は評価しています。私もこれは大事だと思います。
そして修正までの期間は、71日。
2026年2月のPixel security bulletin で修正されました。
Project Zeroとしては、こうしたドライバ脆弱性が90日以内に修正されたのは初めてだと述べています。これはかなり良いニュースです。
脆弱性の発見も大事ですが、修正の速さはさらに大事です。世の中、見つかるだけでは不十分で、直らないと意味がありません。
個人的には、この事例のいちばん面白いところは、攻撃の華やかさよりも、あまりに地味なミスが致命傷になっているところです。
mmap のサイズチェックをちゃんとやる。
マップする範囲を実際のデバイス領域にきちんと制限する。
こういう基本が甘いと、最終的にkernelが丸見えになる。
セキュリティって、派手な暗号よりも、こういう地味な境界チェックで決まることが本当に多いです。
そしてもう一つ大事なのは、Project Zeroが言うように、これは単なる1件の不具合報告ではなく、ドライバ開発全体の姿勢の問題でもあることです。
BigWaveを報告したときに、同じ系統の他ドライバもきちんと見直していれば、今回のVPUの穴はもっと早く見つかったかもしれません。
もちろん外からは言うほど簡単ではないのですが、だからこそ予防的な監査が必要だと思います。
今回のProject Zeroの報告は、Pixel 10での0-click攻撃チェーンの再現だけでなく、Androidドライバの危うさと、修正体制の改善の両方を示しています。
攻撃面ではかなり怖い話ですが、同時に「以前より速く直った」という前進も確認できる、少し複雑な内容です。
率直に言うと、攻撃は面白いが、穴は笑えないというタイプの事例です。
でもこうした公開は、ベンダーに改善を促し、結果としてユーザー全体の安全につながる。そこにProject Zeroの存在意義があるのだと思います。
参考: A 0-click exploit chain for the Pixel 10: When a Door Closes, a Window Opens