Pixel 10 用の 0 クリック攻撃連鎖

我々 Google Project Zero は近日、Google Pixel 9 に存在するexploitチェーンを公開しました。このチェーンにより、ゼロクリックコンテキストから2段階のexploitでAndroidデバイスをroot権限へ至ることが可能であることを示しました。Dolby社のゼロクリック脆弱性（CVE-2025-54957）は、2026 年 1 月のパッチ適用まで全ての Android デバイスに存在していました。Pixel 9 向けにすでに exploitチェーンを有していたため、同様のチェーンを Pixel 10 向けにも記述できるか検証を行いました。

Dolby Exploit の更新

CVE-2025-54957 に対する exploit を改良する作業は比較的単純でした。必要な変更の大部分は、Pixel 9 上で標的としたライブラリの特定バージョンに対して計算されたオフセットを、Pixel 10 のライブラリにおける同等のオフセットに更新することで構成されていました。主な課題（同期フレームにオフセットが含まれているかに関するドキュメントが不足していたことを後知りました）は、Pixel 10 が

-fstack-protector

に代わって RET PAC を採用している点にあります。これにより

__stack_chk_fail

はコードによって上書き利用することが不可能となりました。数回の試行錯誤を経て、デコーダーが初期化される際に一度呼び出され thereafter 二度とは呼ばれないため機能上の問題を引き起こさない

dap_cpdp_init

（初期化コード）を上書きして利用する方針を取りました。

更新後の Dolby UDC exploit は以下の場所から入手可能です。この exploit は未パッチデバイス（SPL が 2025 年 12 月以前のもの）のみで動作します。

BigWave の撤廃と VPU の導入

チェーン内のローカル特権昇格リンクを Pixel 10 へ移植することは不可能でした。これは、BigWave ドライバがこのデバイスには供給されていないためです。一方で、

/dev/vpu

というパスにある mediacodec SELinux コンテキストにおいて新しいドライバが検出されました。このドライバは、Tensor G5 チップ上の Chips&Media Wave677DV シリコンと対話するために使用され、ビデオデコーディングの加速を担うものです。オープンソース C ファイル内のコメントから判断すると、この VPU ドライバの開発・維持は BigWave ドライバを開発した開発者チームが行っていることが確認されました。Jann Horn 氏との連携の下で、この VPU ドライバの監査に 2 時間費やし、画期的な脆弱性を発見しました。

upstream の Linux WAVE521C（旧型 Chips&Media チップ）用ドライバとは異なり、Pixel 向けの WAVE677DV ドライバは V4L2（「Linux を 위한ビデオ API」）との統合を行っておらず、チップのハードウェアインタフェースをユーザスペースに直接公開しています。これにより、ユーザスペースから MMIO レジスタインタフェースにマッピングを行うことが可能になっています。ドライバの主たる役割はデバイスメモリモジュールの設定、電力管理の実行、およびユーザスペースがチップからの割り込み待ちをする許可などです。

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);
    /* これは CSRs のマッピングなので 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 レジスタ領域をユーザランド仮想アドレス空間へとマッピングするためのものであり、これは特定の物理メモリアドレス範囲内に含まれる領域です。この際、VMA のサイズに基づいて

remap_pfn_range

を呼び出し、レジスタ領域のサイズに縛られることなく実装されています。すなわち、

mmap

システムコールでレジスタ領域より大きいサイズを指定することで、呼出側は VPU レジスタ領域の物理アドレスから開始して希望するだけの実メモリー領域をユーザランドへとマッピングできます。カーネルイメージ全体（

.text

および

.data

領域を含む）の物理アドレスは VPU レジスタ領域よりも高い位置に設定されており、したがってこのバグを利用してユーザスペースからアクセス・変更が可能となります。

この時点で、カーネル関数の上書きによりカーネルコードの実行を入手したり、あるいはあらゆる基礎的なプリミティブ操作を実行することも可能になります。さらに、Pixel においてカーネルは常に同一の物理アドレスに配置されるため、VPU メモリ領域とカーネル間のオフセットは常に既知の値となります。そのため、マッピングされた物理メモリ内でカーネルを検索する必要さえなく、

mmap

が返すアドレスに対する相対位置として正確なカーネルの所在が分かっており（VMA の長さを十分大きく設定すれば）、なおさら容易です。

この脆弱性によりカーネルに対する任意の読書きを実現するには 5 行のコードだけで sufficedし、完全な exploit を記述するためには 1 日以下の労力しか要していませんでした。

パッチプロセス

私は当該バグを 2025 年 11 月 24 日に報告し、Android VRP はこれを「High severity」と評価しました。これは、以前 Pixel 9 の特権昇格に利用した BigWave バグ（同等のセキュリティ影響を持ちながら当初は「Moderate severity」と評価されていた）と比較して明確な改善であり、これらのタイプの脆弱性に対する_triage_およびパッチ適用プロセスにおける姿勢の有意義かつ前向きな転換を示しています。当該脆弱性は報告から 71 日後、すなわち同社がこの脆弱性を最初に察知してから 90 日以内にパッチされ、2026 年 2 月の Pixel セキュリティブリンレットに組み込まれました。これは、私が報告した Android ドライバの脆弱性が Vendor の知識入手から初めて 90 日以内のパッチ化を受けた初例であることを踏まえると、特に迅速な対応であったと言えます。

結論

今回の研究からは肯定的にも否定的にも多くの教訓を引き出せます。Project Zero の主要な目標は、単なる個別のバグ修正を超えた体系的改善を推進し、開発プロセスの向上とより強固なコード基盤を促進することでエンドユーザーのセキュリティを高めることにあります。この VPU 脆弱性の対応は、Android の_triage_パイプラインにおける明確な進歩を示しており、前回の BigWave バグよりも短期間で是正措置が講じられた点からその有効性が窺えます。Android が重大な脆弱性を効率的にパッチ化することで多くの Android デバイスを保護しようとする努力は広く評価されるべきです。

一方、今回の事例は Android ドライバにおいて、より徹底的かつセキュリティ意識の高いコードの実装が引き続き必要であることを強調しています。BigWave のバグを報告した際には、開発者が他のドライバにも明らかなセキュリティ問題を評価するよう呼びかけていましたが、5 ヶ月後の現在でも、VPU ドライバにおいて極めて浅薄な重大脆弱性を発見しており、コードベースの表面的な監査ですぐに顕在化しました。ドライバのセキュリティ強化は、安全な Android エコシステムを確保するための重要な優先事項であり、今後も Vendor に対して予防的な取り組みを通じて此类の脆弱性がエンドユーザーに届くことを未然に防ぐようソフトウェア開発プラクティスの改善を強く奨励してまいります。

セキュリティレポートはしばしば製品チームが見落とした複雑な問題を浮き彫りにしますが、特に安全性に直結する製品においては、ソフトウェアベンダが必要となる措置を講じて脆弱性の少ない状態でのリリースを確保し、ソフトウェアチームがプロアクティブにソフトウェアセキュリティ、コード監査、脆弱性のパッチ化に取り組むことが極めて重要であります。