mmap の実装ミスでkernelの広い範囲を userspace から触れるレベルの致命傷があったGoogle Project Zeroが、Pixel 10向けの0-click exploit chainを公開しました。
0-clickというのは、ユーザーが何も操作しなくても攻撃が成立するという意味です。たとえば、怪しいリンクを開く必要も、ファイルを保存する必要もない。攻撃のハードルがかなり低く見えて、実際にはとても危険です。
今回の話は、ざっくり言うとこうです。
つまり、「入口の穴」から入って「出口の穴」で一気に最上階まで登るような攻撃です。
この種の連鎖は、個別のバグ1個よりもずっと厄介です。なぜなら、1つは小さく見える問題でも、つなげると致命傷になるからです。ここが本当に面白いし、同時に嫌なところでもあります。
一般向けに言うと、Android端末の中には何層もの権限があります。
root は管理者権限のことです。
rootを取られると、普通のアプリではできないことがかなり自由にできてしまいます。さらにkernelまで攻撃されると、端末全体の支配に近づきます。
個人的には、ここまで行くと「スマホ」というより、もう「持ち歩くコンピュータの神経系を握られる」感覚に近いと思います。
Project Zeroは、以前Pixel 9向けに公開した exploit chain を、Pixel 10向けにも移植しています。
その入口になったのが、CVE-2025-54957 に関係する Dolby の脆弱性です。
作者によると、Pixel 10版への変更はかなり素直だったそうです。主な作業は、Pixel 9で使ったライブラリのoffset（メモリ上の位置ズレ）を、Pixel 10向けに合わせ直すことでした。
要するに、「同じ建物だけど部屋の配置が少し変わったので、目的の部屋の位置を読み直した」という感じです。
ただし、ひとつ厄介な点がありました。
Pixel 10では、従来の -fstack-protector の代わりに RET PAC が使われていて、__stack_chk_fail を上書きする手口が使えなかったのです。
ここは専門用語が多いですが、簡単にいうと：
そこで彼らは、dap_cpdp_init という初期化コードに目をつけました。
これは一度だけ呼ばれる初期化処理なので、上書きしても機能上の問題が起きにくい。なるほど、こういう「壊れてもバレにくい場所」を探すのが攻撃研究の怖さでもあり、面白さでもあります。
Pixel 9で権限昇格に使ったのは BigWave driver でした。
ところがPixel 10には、そのBigWave driver が載っていません。つまり、前回の“抜け道”は使えない。
普通なら「じゃあ終わり」となりそうですが、Project Zeroはそこで別の入口を見つけます。
Pixel 10の mediacodec SELinux context で、**/dev/vpu** という新しいdeviceが見えていたのです。
このVPU driverは、Tensor G5の Chips&Media Wave677DV というビデオデコード用のハードウェアを扱うものでした。
要するに、動画再生やデコードを高速化するための部品です。
ここで少し感心するのは、開発者たちがBigWave driverと同じ系統の人たちだったらしい、という点です。
つまり、前回の問題を知っているはずの流れで、別のdriverに同じくらい危険な穴が残っていた。これは正直、かなり皮肉です。Door closes, window opens というタイトルは、まさにこの感じですね。
このVPU driverの核心は、mmap の実装にありました。
mmap というのは、ざっくり言えばデバイスのメモリをアプリから見えるようにする仕組みです。
本来は「この範囲だけ触ってね」と安全に区切る必要があります。
ところが問題のコードでは、remap_pfn_range を使うときに、マッピングしてよい範囲をきちんと制限していませんでした。
しかも、指定された VMA のサイズをそのまま信じてしまっていた。
結果として何が起きるかというと、攻撃者が大きめのサイズで mmap を呼ぶだけで、VPUのレジスタ領域の先にある物理メモリまで、ユーザー空間から見えてしまうのです。
ここで重要なのは、Pixelでは kernelの物理アドレスが常に同じ だったことです。
そのため、VPU領域からkernelまでの距離が分かっていれば、メモリを総当たりで探さなくても、どこにkernelがあるか最初からわかる。
これは、攻撃者にとってめちゃくちゃ都合がいいです。
Project Zeroは、この欠陥で kernelに対する arbitrary read-write、つまり「好きな場所を読み書きできる状態」を得るのに、たった5行のコードで済んだと述べています。
しかも、フル exploit の完成まで1日もかからなかったそうです。
これは本当に、読んでいてぞっとするレベルです。バグが浅いというのは、攻撃者にとっては“優しい”という意味でもあるんですよね。
kernelの任意読み書きができると、攻撃者はかなり自由になります。
たとえば、
といったことが現実的になります。
つまり、端末のルールそのものを書き換えるに等しいです。
個人的には、この手のバグが怖いのは「高度な暗号を破った」とか「難解なゼロデイを発見した」ではなく、コードをちょっと見ただけで危険だと分かるタイプだったことです。
こういうのが残っていると、どれだけ防御を積んでも、入り口がドアどころか網戸みたいな状態になってしまうと思います。
Project Zeroはこのバグを2025年11月24日に報告しました。
Android VRP（脆弱性報奨制度）はこれを High severity と評価しています。
ここは以前のBigWaveの話と比べると、改善があったと評価されています。
Pixel 9で使ったBigWaveの問題は、当初は Moderate severity とされていたそうで、同じようなセキュリティ影響なのに評価が低かった。
それに比べると、今回はより重く扱われ、71日後の 2026年2月のPixel security bulletin で修正されたとのことです。
この「90日以内に修正された」のは、かなり良い進展だと思います。
脆弱性が見つかったあと、ベンダーがどれだけ真面目に向き合うかで、被害の広がり方はかなり変わりますからね。
Project Zeroの結論は、単なる「バグ見つけました、修正されました」で終わっていません。
むしろ、プロセス面での改善は評価しつつ、コード品質の甘さはまだ問題だとかなり率直に言っています。
特に印象的なのは、BigWaveの問題を報告した時点で「他のdriverも見直してほしい」と期待していたのに、5か月後に別のdriverで、誰が見ても浅い脆弱性を発見してしまったという点です。
これは正直、痛い話です。
「たまたま見逃した」ではなく、「ちょっと見れば分かるレベル」が残っていたのだから、組織としてのセキュリティ意識が十分だったかは疑わしいと思います。
この件は、単なるPixel 10の脆弱性紹介ではありません。
むしろ、Androidのdriver開発と脆弱性対応が少しずつ良くなっている一方で、まだ油断できないという話だと思います。
良い点は：
悪い点は：
技術的には「Pixel 10で新しい穴を見つけた」という話ですが、もっと本質的には、セキュリティは製品出荷後に頑張るだけでは足りず、最初から壊れにくく作る必要があるという、いつものけれど重要な教訓が詰まっています。
地味だけど、ここがいちばん大事だと思います。
参考: A 0-click exploit chain for the Pixel 10: When a Door Closes, a Window Opens