Pixel 10向けの0クリックエクスプロイトチェーン

2026年5月15日原文(projectzero.google)

概要

Google Pixel 9 のゼロクリックからroot権限取得までのエクスプロイトチェーン公開
Pixel 10 向けに同様のエクスプロイトチェーンを作成
VPUドライバ に重大なカーネル脆弱性発見
脆弱性は 迅速にパッチ適用 され、Androidの対応速度向上を示唆
Androidドライバの セキュリティ強化の必要性 を強調

Pixel 9のエクスプロイトチェーンとDolby脆弱性

ゼロクリック脆弱性 （Dolby）を利用したPixel 9のroot権限獲得エクスプロイトチェーン
脆弱性は Android全体 に存在し、2026年1月にパッチ適用
Pixel 10用のエクスプロイトチェーン作成を目指す動機

Dolby Exploitのアップデート

CVE-2025-54957 向けエクスプロイトのバージョンアップ
Pixel 9用のライブラリの オフセット をPixel 10用に調整
Pixel 10では RET PAC 導入により__stack_chk_failの上書き不可
dap_cpdp_init を上書き対象に選定し、機能的な問題を回避
このエクスプロイトは 未パッチ（SPL 2025年12月以前）端末のみ有効

BigWave削除とVPUドライバの追加

Pixel 10では BigWaveドライバ が非搭載となり、従来の特権昇格リンクは利用不可
新たに /dev/vpu としてVPUドライバがSELinuxコンテキストで確認
Chips&Media Wave677DV 用ドライバで、BigWaveドライバと同じ開発者チームが担当
Jann Horn と協力し、VPUドライバを2時間監査し、深刻な脆弱性を発見

VPUドライバのカーネル脆弱性

vpu_mmap 関数の設計ミスによる物理メモリの無制限マッピング
remap_pfn_range 呼び出し時、VMAサイズの上限チェックがなく、任意の物理メモリ範囲をユーザー空間にマッピング可能
カーネルイメージ（.text, .data領域）へのアクセス・改変が容易
Pixel端末ではカーネル物理アドレスが固定のため、オフセット計算が簡便
任意のカーネル関数上書き によるコード実行、または任意のプリミティブ獲得が可能
5行のコード でカーネル任意読み書き達成、1日未満でフルエクスプロイト完成

パッチ適用プロセスと評価

2025年11月24日 にバグ報告、Android VRPでHigh評価
Pixel 9のBigWaveバグはModerate評価だったが、今回の対応は前進
71日後 （2026年2月Pixelセキュリティ速報）にパッチ公開
Androidドライババグの初回報告から90日以内でのパッチは初

結論と今後の課題

Project Zero の目標は個別バグ修正を超えたシステム的なセキュリティ改善
VPU脆弱性対応はAndroidのトリアージ体制進化を示す
重大な脆弱性の 迅速なパッチ はユーザー保護に寄与
一方で、 ドライバコードの堅牢化 とセキュリティ意識向上が今後も不可欠
BigWave報告後もVPUで即発見できる浅いバグが残存
ベンダーの積極的なコード監査・開発プロセス改善 の継続的推進が重要
セキュリティレポートは複雑な問題を明らかにするが、 製品出荷前の脆弱性排除 と セキュリティ重視の開発文化 が不可欠

Hackerたちの意見

これは素晴らしいバグレポートだね！俺はカーネルの専門家じゃないけど、10年以上前にちょっと読んだことがあるんだ。それでも、内容を追って何が起こっているのか理解できたよ。これが本当にひどいバグだったから、他にどんな危険が潜んでいるのか考えると怖くなる。しかも、見つけるのにそんなに手間がかからなかったしね。あと、最近のセキュリティ問題はAIを使って発生しているのが多いってのも注目すべき点だね。このレポートを見て思ったことは二つ。1. 専門知識はやっぱりめちゃくちゃ価値がある、ニッチな分野ほど価値が高い。2. まだAIが支配していないニッチな分野がたくさんあるってこと。

うーん… 誰か俺の考えをダブルチェックしてほしい。gpt 5.5 xhighにこのプロンプトをそのまま投稿したんだ: does this look right to you? don't do any searches or check memory, just think through first principles 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; } そしたら、ウェブ検索なしで問題を正しく特定してくれたんだ。もっと包括的なことを試してみたいな、例えば特定の関数だけじゃなくてコードベース全体をプロンプトに突っ込むとか。でも、セキュリティの脆弱性を見つける能力は確かにあるみたいだね。だから、そもそもこれがどうやって漏れたのか気になる。おもちゃみたいな例を使ってるけど、もっと学びたいな！

└

こういうひどいコードを書いた人や、それをリリースした会社に対して、何の罰もないのがいつもの問題だよね。もしこのコードを書いた人が一生刑務所に入れられるとか、リスクにさらされたユーザー1人につき100万ドルの罰金を会社に科せられる（それだとGoogleは1兆〜10兆ドルの罰金になって、倒産するかも）ってなったら、状況は全然違ってたと思う。

└

ちょっとしたエピソードだけど、fragnesia.cとその後の提案されたパッチを提供したんだ。新しい脆弱性を発見することはできなかったけど、同じ根本的なバグを利用する新しい方法を2つ見つけられたと思う。たったのClaudeのサブスクリプションを持ってるバカな俺にしては、結構すごいことだよ。

└

どうやってそれがウェブを検索してないってわかったの？

└

コードをインターネット接続なしでClaude Opus 4.7に貼り付けて、関数が何をするのか教えてって頼んだら、説明してくれて、バグも指摘してくれたよ。バグを探してくれって言わなかったのにね。> 観察と潜在的な問題いくつか注意すべきことがあるよ：1. マッピングサイズに対する境界チェックがない。ユーザースペースがvm_end - vm_startとvm->vm_pgoffを制御してる。ここでvm_pgoffは完全に無視されてて、サイズは盲目的に信頼されてる。例えば、VPUのレジスタブロックが64KBだけど、ユーザースペースが1MBのマッピングを要求したら、ドライバはcore->paddrから始まる物理アドレス空間の1MBを喜んでマッピングする。隣接する物理アドレスにあるハードウェアを露出させる可能性があるんだ。防御的なチェックはこうだね：--- 70日間のリリースサイクルでは、オープンソースプロジェクトのすべてのPRをボットがスキャンできるようになったら、広範なエクスプロイトの使用を止めるには速すぎないだろう。

└

それはあまり公平なテストじゃないよね。モデルをかなり引っ張ってるし、プロンプトにバグを見つけるって具体的に書いてなくても。要は、今のモデルが神話と同じくらい良いって主張したスレッドでみんなが言ってたのと同じ反論だよ。

「これは特筆すべき速さだね。俺が報告したAndroidドライバのバグが、ベンダーが脆弱性を初めて知ってから90日以内にパッチが当てられたのは初めてだから。」これを聞いてGoogleに対してちょっと安心したけど、Androidの他の部分にはちょっと怖さも感じる。Appleの対応時間はどうなんだろう？

└

前にAppleにセキュリティバグを報告したことがある。数年前のことだけど、パッチが出るまでに約6ヶ月かかったのを覚えてる（信頼性の高いPOCを得るために何度かやり取りがあった）。100%再現可能なPOCを提出してからは2ヶ月くらいだったかな。

└

Androidのベンダーは、長い間アップデートに関して悪名高いよね。その理由の一部は、すべての電話会社が自分たちを他と差別化したいからで、デフォルトのAndroid UIをフォークして、ブランド特有の機能を持つサイケデリックなUIを提供したいからなんだ。でも、それってストックAndroidのアップデートが出たときに、移行するのがすごく大変になるってこと。

└

現在、Androidデバイスの42%がパッチ未適用ってことを考えると、彼らが研究を公開して全てを脆弱にするっていうのは興味深い決定だね。[1] https://gs.statcounter.com/android-version-market-share [2] https://www.cybersecurity-insiders.com/survey-reveals-over-1...

└

ブランド名のあるAndroidデバイスでは、OSのセキュリティアップデートが受けられることが期待できるよ。ファーストパーティのベンダーが自分たちでこれを構築してプッシュできるからね。ドライバーやファームウェアのセキュリティアップデートは、場合によるかな。これらはしばしば上流のベンダーから来なきゃいけなくて、そのベンダーが問題を修正する気があるかどうかは分からない。小さいブランドは、予算向けのAndroidデバイスを出して、全くアップデートしないことが多いよ。

Hacker Newsで議論の続きを見る