Android / Pixel 脆弱性情報
- Advisory
- Pixel Update Bulletin - February 2026
- Published
- 2026-02-02
- Patch level
- 2026-02-05 or later
- Component
- Pixel
- Subcomponent
- VPU Driver
- Type
- EoP (Elevation of Privilege)
- Severity
- High
- References
- A-463674877 *
- Source
- Pixel Update Bulletin - February 2026
判定できた具体的な脆弱性
- Pixel 10 VPU ドライバの `/dev/vpu` `mmap` ハンドラ `vpu_mmap` における範囲チェック欠落。
- `core->paddr` から `remap_pfn_range` する際、ユーザー指定の VMA 長 `vm_end - vm_start` をVPU MMIO領域サイズと比較せずに使っていた。
- 過大な `mmap` により、VPU MMIO領域を越えた隣接物理メモリ、特にカーネル `.text` / `.data` をユーザー空間へ読み書き可能にできる。
- 根本原因は、`requested_size > vpu_mmio_size` を拒否するチェックが `vpu_mmap` に存在しなかったこと。
特定根拠
- Project Zero の公開 Buganizer issue 463438263 に、`vpu_ioctl.c` の `vpu_mmap` 脆弱コードとPoCクラッシュ説明が含まれていた。
- NVD の CVE-2026-0106 説明が「`vpu_mmap` of `vpu_ioctl`」「missing bounds check」「arbitrary address mmap」と一致していた。
- Pixel Bulletin の表で `CVE-2026-0106 / A-463674877 / EoP / High / VPU Driver` と確認した。
- GoogleSource公開ブランチでは正確な修正コミットは見つからなかったが、修正意味は `mmap` 長をVPUリソースサイズ内に制限することと判断できた。
保存した付帯情報
- 調査フォルダ
001-ok-VPU-mmap-OOB-physical-mapping
- 検証本文
validated.md
- 解析メモ
artifacts/patch-analysis.md
- 探索ログ
artifacts/repository-search-notes.md
- 概念コード
artifacts/repro-sketch.c
validated.md を表示
# CVE-2026-0106 検証結果
## 判定
`ok`。脆弱性と根本原因は特定できた。
公開パッチコミットそのものは、確認した GoogleSource の公開ブランチ上では見つからなかった。一方で、Project Zero の公開 Buganizer レスポンスに `vpu_ioctl.c` の `vpu_mmap` の脆弱コード、到達条件、PoC のクラッシュ結果が含まれており、NVD/CVE本文とも一致する。したがって「ソースコード、もしくは脆弱性が起きる状況を完璧に説明できる場合」という条件は満たす。
## 対象情報
- CVE: CVE-2026-0106
- Pixel bulletin: Pixel / VPU Driver / EoP / High
- Android bug: A-463674877
- Project Zero issue: 463438263
- Project Zero vendor ID: 463432769
- 報告日: 2025-11-24
- 修正日/Pixel Bulletin日: 2026-02-05
- 影響端末として公開報告に出てくる端末: Pixel 10 `frankel`
- 影響ビルド例: `google/frankel/frankel:16/BD3A.251105.010.E1/14337626`
## 何が脆弱だったか
Pixel 10 の VPU ドライバは `/dev/vpu` を公開しており、少なくとも `mediacodec` SELinux コンテキストなどから到達可能だった。`/dev/vpu` の `mmap` ハンドラである `vpu_mmap` は、本来 VPU の MMIO/register 領域だけをユーザー空間へマップする目的の処理だった。
問題は、`vpu_mmap` が VPU の物理ベースアドレス `core->paddr` から `remap_pfn_range` する際、ユーザーが要求した VMA サイズをそのまま使い、実際の VPU レジスタ領域サイズに収まっているかを確認していなかったこと。
結果として、攻撃者は `/dev/vpu` に対して過大な `mmap` サイズを指定できる。マッピングは VPU MMIO の物理ベースから始まるが、長さが制限されないため、隣接する無関係な物理メモリまでユーザー空間に露出する。
## 根本原因
根本原因は `vpu_mmap` の範囲チェック欠落。
本来必要だった検証は、概念的には次の条件:
```c
requested_size = vm->vm_end - vm->vm_start;
if (requested_size > vpu_mmio_size)
return -EINVAL;
```
しかし脆弱版では、`requested_size` が VPU の実リソースサイズ以内かを確認せず、`remap_pfn_range` に渡していた。これにより、ユーザー空間プロセスが VPU レジスタ範囲外の物理ページを読み書き可能にできた。
## なぜ権限昇格になるか
Project Zero の説明では、Pixel ではカーネルが固定の物理アドレスに配置され、かつ VPU MMIO ベースより高い物理アドレスに存在する。そのため、十分大きな `mmap` を要求すると、VPU MMIO から先にあるカーネル `.text` / `.data` 領域までユーザー空間にマップできる。
この状態になると、低権限ユーザー空間からカーネルメモリの任意 read/write に近いプリミティブが得られる。Project Zero のPoCは、カーネルイメージをマップし、`signalfd` の file operations テーブルを書き換え、その後 `signalfd` syscall を呼ぶことで、カーネルが制御されたポインタを参照してクラッシュすることを示している。
報告されたクラッシュでは `x0 = 0x4141414141414141`、`try_module_get` で fault、call trace に `anon_inode_getfd` と `do_signalfd4` が出ている。これは単なるDoSではなく、カーネル内の関数テーブル/オブジェクトポインタをユーザー空間から改変できていることを示す。
## パッチ解析
公開されている正確な修正コミットは見つからなかった。確認した範囲:
- `kernel/google-modules/soc/gs`: `vpu_ioctl.c` / `vpu_mmap` / Wave677DV は見つからず。
- `kernel/google-modules/video/gchips`: BigWave (`bigo_*`) はあるが、Pixel 10 VPU の `vpu_ioctl.c` は見つからず。
- 既存の `../binaries/kernel_google-modules_video_gchips.git`: BigWaveのみで、対象VPUソースなし。
- 既存の `../binaries/pixel_shiba_ota`: Pixel 8 Pro `shiba` OTAであり、Pixel 10 `frankel` ではない。
ただし、修正の意味は明確。`vpu_mmap` は、`remap_pfn_range` 前に要求サイズを VPU MMIO リソースサイズと比較し、範囲外なら拒否する必要がある。別解として、VPU MMIO領域以外のPFNをユーザー空間に渡さないよう、platform resource の `resource_size()` 由来のサイズで上限チェックする実装でもよい。
## 面白い点・調査メモ
- Android February 2026 Bulletin 側には該当CVE表がなく、Pixel Bulletin 側にだけ `VPU Driver` として掲載されている。
- Project Zero は「Source review」で発見したと記録している。複雑なraceやUAFではなく、`mmap` サイズ検証がないだけの非常に浅いバグ。
- `/dev/vpu` が `mediacodec` から届く点が重要。メディア解析系の1-click/0-click脆弱性からこのLPEへ接続できるため、単体ではLocal EoPでも exploit chain 上の価値が高い。
- BigWave がPixel 10に存在しないため、Project Zeroは新しいVPUドライバを見た。過去のBigWave系と同じ開発者コメントがあり、同種の「ハードウェアIFをユーザー空間へ強く露出する」設計が続いていたことが示唆される。
- Project Zero のPoC説明では、完全なroot exploitではなく制御PC相当のクラッシュ証明を示している。それでも、マップ済み物理メモリ経由でカーネル `.text` / `.data` を書けるため、実用的な権限昇格プリミティブとして十分。
## 付帯ファイル
- `artifacts/project-zero-463438263-action-response.txt`: Project Zero Buganizer APIレスポンス保存。
- `artifacts/project-zero-pixel10-exploit.html`: Project Zeroブログ保存。
- `artifacts/nvd-cve-2026-0106.html`: NVDページ保存。
- `artifacts/patch-analysis.md`: パッチ/根本原因の短い技術メモ。
- `artifacts/repository-search-notes.md`: 公開リポジトリと既存バイナリの探索結果。
- `artifacts/repro-sketch.c`: 悪用コードを含まない、過大 `mmap` 到達条件確認用の概念コード。
## 参照
- Pixel Update Bulletin - February 2026: https://source.android.com/docs/security/bulletin/pixel/2026/2026-02-01
- NVD CVE-2026-0106: https://nvd.nist.gov/vuln/detail/CVE-2026-0106
- Project Zero issue 463438263: https://project-zero.issues.chromium.org/issues/463438263
- Project Zero blog: https://projectzero.google/2026/05/pixel-10-exploit.html