Project Zeroが Pixel 10 のゼロクリック・ルート奪取チェーンを公開 — Dolby UDC + Tensor G5 VPUの「5行で任意カーネルread-write」

この記事は約15分で読めます。

Google の脆弱性研究チーム Project Zero は2026年5月13日、最新フラッグシップ Pixel 10 に対する完全なゼロクリック・エクスプロイトチェーンの研究結果を公開しました。Seth Jenkins 氏が執筆した本ポスト「A 0-click exploit chain for the Pixel 10: When a Door Closes, a Window Opens」は、2026年1月に公開された Pixel 9 のゼロクリックチェーン3部作の続編に位置付けられる内容です。なお、VPU ドライバの監査は Jann Horn 氏との共同作業として行われています。攻撃チェーンは2つの脆弱性で構成されており、第1段が Dolby Unified Decoder(UDC)の CVE-2025-54957、第2段が Pixel 10 の VPU ドライバ脆弱性 CVE-2026-0106 です。後者は Tensor G5 チップ上の VPU ドライバの mmap ハンドラにおける境界チェック欠落で、Jenkins 氏らがわずか2時間の監査で発見し、わずか5行のコードで任意のカーネル read-write を達成できる「例外的なまでに浅い脆弱性」だったと報告されています。本記事では公開情報をもとに、攻撃チェーンの構造、技術的な要点、そして Android エコシステム全体への含意を整理します。

背景:Pixel 9 ゼロクリックチェーンの続編として

本研究の出発点は、2026年1月に Project Zero が公開した Pixel 9 向けのゼロクリック・ルート奪取チェーンです。当時のチェーンは Dolby UDC の CVE-2025-54957(音声デコーダの脆弱性)と、Pixel SoC 上の AV1 デコードアクセラレータ /dev/bigwave ドライバの脆弱性を組み合わせ、「ユーザーがメッセージを開くまでもなく Android デバイスで root 権限を取得する」ことが2つのエクスプロイトで可能であると示したものでした。今回の Pixel 10 向け研究は、同じアプローチが Google の最新世代デバイスでも成立するかを検証する続編です。結論から述べると、答えは「成立する」でした。しかも、第1段は Pixel 9 向けのエクスプロイトをほぼ流用でき、第2段は2時間の監査で新たに発見した別のドライバの脆弱性で代替できた、という構図です。

第1段:Dolby UDC の CVE-2025-54957 を Pixel 10 向けに調整

第1段は Pixel 9 と同じ Dolby Unified Decoder(UDC)の CVE-2025-54957 を使用します。Dolby UDC は Dolby Digital 系の音声フォーマットを処理するライブラリで、Android、iOS、Windows、メディアストリーミングデバイスなど広範な環境に組み込まれています。Android においては、Google Messages が受信した音声メッセージをユーザーが開封する前に自動的に文字起こし(transcription)するため、Dolby UDC は事実上ほとんどの Android デバイスのゼロクリック攻撃面に含まれている、という構造的な問題があります。

Project Zero によれば、Pixel 9 向けのエクスプロイトを Pixel 10 に移植する作業は「比較的単純(fairly straightforward)」だったとされます。主な調整作業は、ライブラリのバージョン差に応じたオフセット計算の更新です。ただし1点だけ技術的なハードルがありました。Pixel 10 では -fstack-protector の代わりに RET PAC(Return Address Pointer Authentication) が採用されているため、Pixel 9 で使われていた __stack_chk_fail の上書きという常套手段が使えなくなっていました。Project Zero は試行錯誤の末、デコーダ初期化時に一度しか呼ばれず後続の機能に影響しない関数 dap_cpdp_init を上書きターゲットとすることで、この制約を回避しています。

この第1段エクスプロイトは、Dolby UDC の CVE-2025-54957 が既に修正されているデバイスでは動作しません。Pixel 向けには2025年12月の Pixel security bulletin で配布、一般 Android 向けには2026年1月の Android Security Bulletin で配布されたパッチが対象です。したがって、SPL(Security Patch Level)が2025年12月以前のままの Pixel、または2026年1月以前のままの他社 Android デバイスでは、依然として攻撃の入口が開いた状態にあると整理できます。

第2段:BigWave の代替として登場した /dev/vpu ドライバ

第2段の権限昇格は、Pixel 9 で使用された /dev/bigwave ドライバが Pixel 10 では同梱されていないため、別のドライバを探す必要がありました。Pixel 10 の mediacodec SELinux コンテキストから可視なドライバとして新たに登場したのが /dev/vpu です。これは Tensor G5 チップ上に搭載された Chips&Media 社の Wave677DV シリコン(ビデオデコードアクセラレータ)とやり取りするためのドライバで、オープンソース C ファイル内のコメントによれば、BigWave ドライバを開発・保守している開発者と同じチームが手掛けたもの でした。

Jenkins 氏は Jann Horn 氏と共同で、この VPU ドライバを2時間にわたり監査しました。その結果として発見されたのが、本記事の核心となる脆弱性です。注目すべきは、上流の Linux カーネルが提供する旧世代 Chips&Media チップ WAVE521C 向けのドライバが V4L2(Video for Linux API)と統合されているのに対し、Pixel の WAVE677DV 向けドライバは V4L2 を経由せず、ハードウェアインタフェースを直接ユーザースペースに公開している 点です。具体的には、デバイスメモリのマッピング、電源管理、ハードウェア割り込みの待機といった機能を、ユーザースペースのプログラムが直接扱えるように設計されていました。

カーネル脆弱性の「聖杯」:vpu_mmap の境界チェック欠落

Project Zero が「The Holy Grail of Kernel Vulnerabilities(カーネル脆弱性の聖杯)」と評した vpu_mmap ハンドラのコードは次の通りです。

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 ハンドラは、VPU ハードウェアの MMIO レジスタ領域(特定の物理アドレス範囲内に存在)をユーザースペースの仮想アドレス空間にマップするためのものです。問題は、remap_pfn_range に渡される長さが純粋に VMA のサイズ(vm->vm_end - vm->vm_start)だけに基づいており、レジスタ領域の実サイズで境界制限されていない 点にあります。

この欠落により、ユーザースペースから mmap システムコールに対してレジスタ領域より十分大きなサイズを指定するだけで、VPU レジスタ領域の物理アドレスを起点として、その後ろにある任意の物理メモリ範囲をユーザースペースにマップできてしまいます。そして、カーネルイメージ(.text および .data 領域)は VPU レジスタ領域より高い物理アドレスに配置されているため、ユーザースペースのプロセスが直接アクセス・改変できるという結論になります。

さらに深刻なのは、Project Zero の別の研究で示されているように、Pixel デバイスではカーネルが常に同じ物理アドレスに配置されています。したがって、VPU レジスタ領域とカーネルの相対オフセットは既知です。物理メモリをスキャンしてカーネルの位置を探す必要すらなく、mmap が返したアドレスから既知のオフセットを足すだけでカーネルに到達できます。

結果として、この脆弱性によりカーネルに対する任意の read-write プリミティブを得るために必要だったコードは わずか5行、完全なエクスプロイトを書き上げるのに要した時間は 1日未満 でした。第2段の権限昇格としては、これ以上望めない条件です。

パッチプロセス:71日でのフィックスは「Android初」

本 VPU 脆弱性は CVE-2026-0106 として採番されています。NVD の説明でも「vpu_mmap of vpu_ioctl における境界チェック欠落によって、任意アドレスへの mmap が可能となり、ローカル権限昇格につながる」とされており、Project Zero の解説と整合しています。CISA-ADP(CISA Authorized Data Publisher)が付与した CVSS v3.1 スコアは 9.3(Critical)、ベクターは AV:L/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:H で、本稿執筆時点では NVD 独自の評価は未提供です。Scope:Changed が付与されている点が、サンドボックス境界(mediacodec SELinux コンテキスト)を超えてカーネルに到達できるという本脆弱性の性質を反映しています。

パッチプロセスに目を向けると、過去の Project Zero による Android ドライバ報告と比較するとはっきりとした改善が見られます。Jenkins 氏が脆弱性を報告したのは2025年11月24日。Android VRP(Vulnerability Rewards Program)は本件を High severity として評価しました。これは、Pixel 9 の権限昇格に使われた BigWave のバグ(影響範囲は同等)が当初 Moderate と評価されていたことと比較すると、トリアージ姿勢の有意な改善といえます。

パッチは報告から71日後、2026年2月の Pixel security bulletin でリリースされました。Project Zero 自身が「自分が報告した Android ドライバのバグが、ベンダーが最初に知ってから90日以内にパッチされたのは今回が初めて」と明記している通り、これは Android のドライバセキュリティ対応における歴史的に注目すべき節目です。

防御側の観点では、Pixel 10 の VPU ドライバ脆弱性 CVE-2026-0106 は、2026年2月の Pixel security bulletin で修正されています。したがって、Pixel デバイスでは SPL(Security Patch Level)が2026-02-05以降 であれば、この第2段の権限昇格脆弱性に対する修正が含まれています。Pixel 10 ユーザーは設定画面から SPL を確認することが推奨されます。

AI機能がゼロクリック攻撃面を広げ、組織横断的な学習が追いついていない

本研究から読み取れる構造的な論点は、技術的な詳細を超えて2つあります。

第1に、AI機能の付加によってゼロクリック攻撃面が広がる構造 です。Google Messages の音声メッセージ自動転写は、ユーザー体験向上のための AI 機能ですが、結果として「メッセージを開く前にメディアデコーダがすべての受信音声を処理する」状態を作り出しました。これにより、本来「ユーザーがメッセージを開いた時点で初めて成立する」攻撃面だったメディアデコーダが、純粋なゼロクリック攻撃面に変わってしまっています。今回の Pixel 10 チェーンも、攻撃の入口は Dolby UDC、すなわちこの自動転写機能の存在に依存しています。これは Android に限った話ではなく、iOS の iMessage プレビュー機能や同種の自動処理機能を持つあらゆるメッセージングプラットフォームに共通する課題です。AI 機能の追加が「攻撃面の意図せざる拡張」を伴うという点は、今後 Android/iOS の両陣営でセキュリティ研究の中心テーマになっていく見込みです。

第2に、「同じ開発チームが書いた別ドライバに同じパターンの脆弱性」が放置されていた という Android エコシステム特有の問題です。Jenkins 氏は今回のポストで明確に、「BigWave のバグを報告した時点で、同じチームが手掛けた他のドライバも自主的に監査することを期待した。しかし5ヶ月後の時点で、彼らの VPU ドライバには表面的な監査でも即座に見つかるレベルの深刻な脆弱性が依然として存在していた」と批判しています。個別のバグを修正することと、組織横断的にコードベース全体を見直すことは別のプロセスであり、後者が機能していないことが浮き彫りになっています。VPU ドライバが V4L2 という標準的な抽象化レイヤを経由せず、ハードウェアインタフェースを直接ユーザースペースに公開している設計判断そのものも、セキュリティ視点からの初期レビューが不十分だった可能性を示唆します。

パッチ速度が改善した点は確かに評価できますが、Project Zero 自身が結びで述べているように、「ベンダーは、特にセキュリティクリティカルなソフトウェアにおいて、合理的に脆弱性のない状態でリリースし、コード監査と脆弱性パッチに対してプロアクティブに取り組む必要がある」という指摘は変わらず重要です。OS/チップベンダー側の品質保証プロセス、そしてサードパーティドライバ提供者との連携体制を含めた、より上流からの取り組みが求められる構図といえます。

実務的な含意

Android/Pixel デバイスを業務で利用している組織が本研究から得るべき実務的なポイントは次の通りです。

  • Pixel デバイスは SPL 2026-02-05以降であれば本チェーンから保護されている。デバイス管理基盤(MDM)から組織内端末の SPL を確認し、未適用端末がある場合は更新を促す運用が必要です。
  • 他社 Android デバイスは Dolby UDC の修正状況がベンダー依存。Samsung、OnePlus、Xiaomi、その他 OEM ベンダーの2026年1月以降のセキュリティアップデート適用状況を確認する必要があります。一般 Android Security Bulletin の January 2026 で配布されたパッチが該当します。
  • Google Messages の音声メッセージ自動転写機能の利用ポリシーを確認する。本研究では、受信音声メッセージがユーザー操作なしにデコードされることがゼロクリック攻撃面につながると示されています。端末・アプリバージョン・管理ポリシーによって制御可否は異なるため、高リスク業務に従事する従業員(経営層、法務、研究開発、メディア対応など)については、機能設定や RCS / MMS の自動処理ポリシーを確認する価値があります。
  • 本チェーンは「研究目的の完全なエクスプロイト」が公開された状態である。Project Zero は教育・防御目的で技術詳細を公開していますが、攻撃者側がこれを応用してより実用的なエクスプロイトを構築する可能性は排除できません。SPL 適用の優先度を再評価する材料にすべきです。

所感:「ゼロデイを難しくする」という Project Zero のスローガン

Project Zero のブログポストは「Make zeroday hard.」という一文で締めくくられています。これは Project Zero が長年掲げてきたスローガンで、「個別のバグを修正するだけでなく、攻撃者がゼロデイを発見・武器化するコスト自体を上げる」ことを目指す姿勢を表しています。今回の Pixel 10 研究は、その文脈で見ると複雑なメッセージを発しています。一方で、パッチ速度の改善(90日以内、Android ドライバとして初)と Pixel 10 の RET PAC 採用といった防御強化は、確実な進歩です。他方で、開発チーム横断のコードレビュー文化が育っていない、AI 機能の付加によって攻撃面が広がるという構造的問題は残ったままで、攻撃者にとっては依然として「2時間で見つかる、5行で書ける」レベルのバグが手の届く範囲にあります。Project Zero の主張は、後者の解消なしには「ゼロデイを難しくする」というゴールには届かない、というものです。Android/Pixel エコシステムにとって、本研究は「進歩の確認」であると同時に「次の取り組みへの督促状」でもあります。

主要ソース

一次ソース

参考情報

slug: project-zero-pixel-10-zero-click-exploit-chain

コメント

タイトルとURLをコピーしました