Android / Pixel 2026-04 CVE 検証サマリ

# CVE-2026-0049

## Summary

- Program target: Android Security Rewards Program
- Advisory: Android Security Bulletin - April 2026
- Published: 2026-04-06
- Updated: 2026-04-08
- Security patch level: 2026-04-01
- Component: Framework
- Type: DoS
- Severity: Critical
- Updated AOSP versions: 14, 15, 16, 16-qpr2
- References: A-456471290, additional AOSP change reference 2

## Advisory Information

The Android April 2026 bulletin describes this Framework vulnerability as a local denial of service issue requiring no additional execution privileges and no user interaction. The bulletin identifies it as the most severe issue for the month.

## Bounty Scope Decision

Included. This is an Android Framework vulnerability documented in the Android Security Bulletin with AOSP version coverage. It is not listed as Linux kernel, external OSS, or a third-party vendor component.

## Source

- https://source.android.com/docs/security/bulletin/2026/2026-04-01

# CVE-2026-0049 検証結果

## 判定

OK。ソースコード差分、追加テストファイル、DNG OpcodeListの実値、unsigned overflow sanitizer付きの最小再現で、脆弱性の条件と修正意図を説明できた。

## 概要

CVE-2026-0049 は、Android Framework の `LocalImageResolver` 経由でDNG/TIFF系画像を `ImageDecoder` に渡せることと、DNG SDK側の `dng_opcode_MapTable::ProcessArea()` にあるPlane範囲計算の32-bit unsigned overflowが組み合わさったローカルDoSと判断した。

攻撃者が細工したDNGを、通知のMessagingStyle/ConversationStyle画像など `LocalImageResolver` が処理する画像として到達させると、DNGデコード中に `MapTable` opcodeが処理される。問題の入力では `Plane + Planes` が `uint32_t` の範囲を超える。Androidのサニタイザ設定ではこのunsigned overflowがruntime errorとして扱われ、デコード処理側プロセスをabortさせる。

## 参照したAOSP修正

- Android Security Bulletin: https://source.android.com/docs/security/bulletin/2026/2026-04-01
- `external/dng_sdk`: `80a267ed1ac714acff455e85ae28c1732777d5b6`
  - Commit message: `Handle underflows in dng_opcode_MapTable`
  - 対象: `source/dng_misc_opcodes.cpp`
- `frameworks/base`: `78ec493d6192240da0d0d37be93c6921eff403e7`
  - Commit message: `Add mimetype filter to LocalImageResolver`
  - 対象: `core/java/com/android/internal/widget/LocalImageResolver.java`
  - 追加テスト: `core/tests/coretests/res/raw/dng_opcode_MapTable_ProcessArea.png`

## パッチ差分から分かったこと

### dng_sdk側

修正前の `dng_opcode_MapTable::ProcessArea()` は以下のように、開始PlaneとPlane数を加算して終端Planeを作っていた。

```cpp
for (uint32 plane = fAreaSpec.Plane ();
     plane < fAreaSpec.Plane () + fAreaSpec.Planes () &&
     plane < buffer.Planes ();
     plane++)
```

修正後は、加算で終端を作らず、`plane - planeStart < planeCount` で範囲内かどうかを判定する形に変わった。

```cpp
const uint32 planeStart = fAreaSpec.Plane ();
const uint32 planeCount = fAreaSpec.Planes ();
const uint32 bufferPlanes = buffer.Planes ();

for (uint32 plane = planeStart;
     plane < bufferPlanes &&
     plane - planeStart < planeCount;
     ++plane)
```

根本的な差は `planeStart + planeCount` を評価しなくなったこと。DNGの `dng_area_spec::GetData()` は `fPlanes < 1` と `rowPitch/colPitch < 1` しか拒否しておらず、`fPlane + fPlanes` が `uint32_t` でオーバーフローしないことを保証していなかった。

### Framework側

修正前の `LocalImageResolver.onHeaderDecoded()` は画像サイズの上限だけを見ており、DNG/TIFF系のような複雑なコーデックも `ImageDecoder` に渡せた。

修正後は `ImageDecoder.ImageInfo.getMimeType()` を確認し、以下のMIMEだけを許可する。

- `image/png`
- `image/jpeg`
- `image/webp`
- `image/gif`
- `image/bmp`
- `image/x-ico`
- `image/vnd.wap.wbmp`
- `image/heif`
- `image/heic`
- `image/avif`

DNGは許可リストに含まれないため、`LocalImageResolver` の時点で `RuntimeException` になり、外側で `IOException` として扱われる。追加テストも `dng_opcode_MapTable_ProcessArea.png` に対して `IOException` を期待している。

## 追加テストファイルの解析

`frameworks/base` の修正で追加された `dng_opcode_MapTable_ProcessArea.png` は、拡張子は `.png` だが実体はPNGではない。

ローカル解析結果:

```text
file: TIFF image data, little-endian, direntries=52, height=144, width=256
sha256: cb576e523bcc7f476d8227b534a6c4e2ed31dc6533561c5bebe961955971d581
size: 87460 bytes
```

`tiffdump` ではIFD0に異常な値も見える。

```text
ImageWidth  = 256
ImageLength = 3892314256
SubIFD      = 12580
```

SubIFD `12580` のタグ `51009`、つまりDNG `OpcodeList2` を復元すると、3個のopcodeが入っていた。問題の3個目は `MapTable`。

```text
Opcode[2] id=7 MapTable
area.t=195
area.l=-1979711488
area.b=338
area.r=600
plane=65535              0x0000ffff
planes=4294901761        0xffff0001
rowPitch=13
colPitch=241
table_count=16
```

ここで旧コードの終端計算は次の通り。

```text
0x0000ffff + 0xffff0001 = 0x100000000
```

`uint32_t` では `0x00000000` に桁あふれする。

## 最小再現

`analysis/reproduce_plane_overflow.cpp` に、追加テストDNGから復元した `plane` と `planes` を使った最小再現を書いた。

実行コマンド:

```sh
clang++ -std=c++17 -fsanitize=unsigned-integer-overflow \
  -fno-sanitize-recover=unsigned-integer-overflow \
  analysis/reproduce_plane_overflow.cpp \
  -o analysis/reproduce_plane_overflow
./analysis/reproduce_plane_overflow
```

結果:

```text
runtime error: unsigned integer overflow: 65535 + 4294901761 cannot be represented in type 'uint32_t'
exit_status=134
```

これはAndroid実機でのクラッシュログではないが、パッチが消した算術式そのものに対して、サニタイザがabort対象のruntime errorを出すことを確認できる。

## 脆弱性の根本原因

根本原因は、DNG Opcodeの外部入力値 `fPlane` と `fPlanes` を信頼したまま、`uint32_t` 加算で終端Planeを計算していたこと。

`dng_area_spec::GetData()` は `fPlanes >= 1` だけを検証し、`fPlane + fPlanes` のオーバーフローを検証していない。そのため、DNG内の `MapTable` opcodeに `plane=0x0000ffff`、`planes=0xffff0001` のような値を入れられると、`ProcessArea()` のループ条件評価でunsigned overflowが発生する。

Framework側の根本的な問題は、通知・会話画像向けの軽量な画像解決クラスである `LocalImageResolver` が、実際にはDNGのような複雑で攻撃面の大きいコーデックまで許可していたこと。サイズ制限はあったが、コーデック種別の制限がなかった。

## どういう脆弱性だったか

ローカルアプリなどが細工した画像URIまたはリソースを `LocalImageResolver` の処理経路へ渡す。`LocalImageResolver` はパッチ前、DNG MIMEを拒否しないため `ImageDecoder` がDNGデコードへ進む。DNG内の `OpcodeList2` に含まれる `MapTable` opcodeで `Plane + Planes` がoverflowし、unsigned integer overflow sanitizerによりabortする。影響はローカルDoS。

アドバイザリの「no additional execution privileges needed」「User interaction is not needed」は、攻撃者が特権なしで通知などのローカル処理経路に画像を渡し、ユーザー操作なしにシステムUI/通知表示側の画像解決を誘発できる、という形と整合する。

## 面白い点・調査メモ

- CVEはFrameworkコンポーネントとして掲載されているが、修正は `frameworks/base` だけでなく `external/dng_sdk` にも入っている。
- `frameworks/base` のテストファイル名は `.png` だが、実体はTIFF/DNG。拡張子や表面的な名前ではなく、`ImageDecoder` が見たMIME/ヘッダで処理される。
- `LocalImageResolver` の修正はDNG SDKのバグそのものを直すものではなく、通知画像の攻撃面からDNGなどを外す防御層。
- `dng_sdk` の修正は `MapTable` だけに入っている。同じような `fAreaSpec.Plane() + fAreaSpec.Planes()` 形のループは `MapPolynomial`、`DeltaPerRow`、`DeltaPerColumn`、`ScalePerRow`、`ScalePerColumn` にも残っているように見える。ただし今回の追加テストとCVE対象は `MapTable`。
- `ScaledOverlap()` には `DNG_ATTRIB_NO_SANITIZE("unsigned-integer-overflow")` が追加されている。こちらはDNG SDK内で意図的または既存許容されていたunsigned演算をサニタイザ対象から外す変更で、CVEの中心は `MapTable::ProcessArea()` のPlane範囲計算修正と見ている。

## 付帯ファイル

- `analysis/80a267ed-dng_sdk.patch`: DNG SDK側のAOSP差分
- `analysis/78ec493-frameworks-base.patch`: Framework側のAOSP差分
- `analysis/dng_misc_opcodes_before.cpp`: DNG SDK修正前ソース
- `analysis/dng_misc_opcodes_after.cpp`: DNG SDK修正後ソース
- `analysis/LocalImageResolver_before.java`: Framework修正前ソース
- `analysis/LocalImageResolver_after.java`: Framework修正後ソース
- `analysis/dng_opcode_MapTable_ProcessArea.png`: AOSPテストから取得したDNGサンプル
- `analysis/tiffdump.txt`: IFD0のTIFF解析結果
- `analysis/tiffdump-subifd-12580.txt`: SubIFD解析結果
- `analysis/opcodelist2_decode.txt`: OpcodeList2の復元結果
- `analysis/reproduce_plane_overflow.cpp`: 算術overflowの最小再現
- `analysis/reproduce_plane_overflow.out`: サニタイザ付き実行結果

# CVE-2025-48651

## Summary

- Program target: Android / Google Devices Security Rewards Program
- Advisory: Android Security Bulletin - April 2026
- Published: 2026-04-06
- Updated: 2026-04-08
- Security patch level: 2026-04-05
- Component: Google
- Subcomponent: StrongBox
- Severity: High
- References: A-434039170

## Advisory Information

The Android April 2026 bulletin lists this issue under Google components. The advisory states that details are available directly from Google and that the severity assessment is provided directly by Google.

## Bounty Scope Decision

Included only for the Google StrongBox row. The same CVE also appears in the NXP components, STMicroelectronics, and Thales sections, but those rows are third-party vendor components and were excluded from this bounty-focused collection.

## Excluded Vendor Rows For This CVE

- NXP components / StrongBox / A-467765081
- STMicroelectronics / StrongBox / A-467765894
- Thales / StrongBox / A-467762899

## Source

- https://source.android.com/docs/security/bulletin/2026/2026-04-01

# CVE-2025-48651 検証結果

## 判定

OK。公開AOSPソース `platform/external/libese` に、Android bug ID `434039170` 付きの修正コミット `0556b32e9ef16b2209842f09169b908149ef2ff4` があり、CVE説明に出ている `KMKeymasterApplet.java` の `importWrappedKey` 周辺の根本原因をソースコード差分から説明できる。

## 概要

CVE-2025-48651 は、Google StrongBox / KeyMint JavaCard実装の `importWrappedKey` における入力検証・信頼境界の問題。公開OSV/NVDの説明では、`KMKeymasterApplet.java` の `importWrappedKey` において、不適切な入力検証により制限されるべき鍵へアクセスできる可能性があり、ローカル情報漏えいにつながる、とされている。

調査した修正コミットでは、`importWrappedKey` の実装が以下の2点で修正されている。

1. `KeyDescription` の解析をHAL側からStrongBoxアプレット内へ移動
2. `AuthorizationList` 内の `USER_SECURE_ID` を、`passwordSid` または `biometricSid` に正しく置換

これにより、インポートされる鍵の制限情報が、暗号的に認証された `KeyDescription` に基づいてStrongBox内で決定されるようになった。

## 参照した公開情報

- Android Security Bulletin - April 2026
  - `CVE-2025-48651`
  - `A-434039170 *`
  - Severity: High
  - Subcomponent: StrongBox
- OSV `ASB-A-434039170`
  - Details: `In importWrappedKey of KMKeymasterApplet.java, there is a possible way access keys that should be restricted due to improper input validation.`
- NVD `CVE-2025-48651`
  - CVSS v3.1: `AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:N`
  - CWE: `CWE-20 Improper Input Validation`
- AOSP `platform/external/libese`
  - Commit: `0556b32e9ef16b2209842f09169b908149ef2ff4`
  - Subject: `Refine the importWrappedKey function implementation`
  - Bug: `434039170`

注: 解析対象の修正前後ソースは、現在のcheckoutのHEADではなく、上記コミット `0556b32` とその親から直接取得した。`external/libese` はKeyMintバージョン別ツリーと共通ツリーの履歴移動があるため、HEAD上の個別KM300ファイルではなく、Bug ID付きコミットそのものを根拠にした。

## KeyMint仕様上の前提

`IKeyMintDevice.importWrappedKey()` の仕様では、`wrappedKeyData` に以下のASN.1構造が含まれる。

```text
KeyDescription ::= SEQUENCE(
    keyFormat INTEGER,
    keyParams AuthorizationList,
)

SecureKeyWrapper ::= SEQUENCE(
    version INTEGER,
    encryptedTransportKey OCTET_STRING,
    initializationVector OCTET_STRING,
    keyDescription KeyDescription,
    encryptedKey OCTET_STRING,
    tag OCTET_STRING
)
```

重要なのは、`encryptedKey` はAES-GCMで暗号化され、そのAADとしてDERエンコードされた `keyDescription` が使われる点。つまり、`keyDescription` は暗号的に認証された鍵属性であり、StrongBoxがインポート後の鍵に適用すべき `keyFormat` と `keyParams` の根拠になる。

また仕様上、`wrappedKeyData` のAuthorizationListに `USER_SECURE_ID` が含まれる場合、値に `PASSWORD` bitがあれば `passwordSid`、`FINGERPRINT` bitがあれば `biometricSid` に鍵を束縛する必要がある。

## 修正前の問題

修正前のHAL側 `JavacardKeyMintDevice::importWrappedKey()` は、`parseWrappedKey()` で `wrappedKeyData` をパースし、`authList` と `keyFormat` を取り出していた。

```cpp
vector<KeyParameter> authList;
KeyFormat keyFormat;
std::vector<uint8_t> wrappedKeyDescription;
keymaster_error_t errorCode = parseWrappedKey(wrappedKeyData, iv, transitKey, secureKey, tag,
                                              authList, keyFormat, wrappedKeyDescription);
```

その後、StrongBoxアプレットへ `authList` と `keyFormat` をAPDU引数として渡していた。

```cpp
sendFinishImportWrappedKeyCmd(
    authList, keyFormat, secureKey, tag, iv, wrappedKeyDescription, passwordSid, biometricSid);
```

修正前のアプレット側 `finishImportWrappedKeyCmd()` も、ホスト側から `Key Params` と `Key Format` を受け取る8引数APIだった。

```java
KMArray.cast(cmd).add((short) 0, params); // Key Params of wrapped key
KMArray.cast(cmd).add((short) 1, KMEnum.instance(KMType.KEY_FORMAT)); // Key Format
KMArray.cast(cmd).add((short) 2, KMByteBlob.exp()); // Wrapped Import Key Blob
KMArray.cast(cmd).add((short) 3, KMByteBlob.exp()); // Auth Tag
KMArray.cast(cmd).add((short) 4, KMByteBlob.exp()); // IV - Nonce
KMArray.cast(cmd).add((short) 5, KMByteBlob.exp()); // Wrapped Key ASSOCIATED AUTH DATA
KMArray.cast(cmd).add((short) 6, KMInteger.exp()); // Password Sid
KMArray.cast(cmd).add((short) 7, KMInteger.exp()); // Biometric Sid
```

そして `processFinishImportWrappedKeyCmd()` は、ホストから受け取った `keyParameters` と `keyFmt` をそのままインポート処理に使っていた。

```java
short keyParameters = KMArray.cast(cmd).get((short) 0);
short keyFmt = KMArray.cast(cmd).get((short) 1);
keyFmt = KMEnum.cast(keyFmt).getVal();
validateImportKey(keyParameters, keyFmt);
...
data[KEY_PARAMETERS] = keyParameters;
importKey(apdu, keyFmt, scratchPad);
```

問題は、StrongBoxの信頼境界内で、暗号的に認証された `wrappedKeyDescription` から `keyFormat` / `keyParams` を再構成していなかったこと。KeyDescriptionはAES-GCM AADとして保護されているのに、アプレットはそれ自体を信頼根拠にせず、HAL/ホストから別引数として来る `keyParameters` / `keyFmt` を信じていた。

## 修正後の挙動

修正後のHALは、`parseWrappedKey()` から `authList` と `keyFormat` を受け取らなくなった。

```cpp
keymaster_error_t errorCode =
    parseWrappedKey(wrappedKeyData, iv, transitKey, secureKey, tag, wrappedKeyDescription);
```

`sendFinishImportWrappedKeyCmd()` も、`secureKey`、`tag`、`iv`、`wrappedKeyDescription`、`passwordSid`、`biometricSid` だけを送る。

```cpp
sendFinishImportWrappedKeyCmd(
    secureKey, tag, iv, wrappedKeyDescription, passwordSid, biometricSid);
```

アプレット側APIも6引数へ縮小され、`Key Params` と `Key Format` をホストから受け取らなくなった。

```java
KMArray.cast(cmd).add((short) 0, KMByteBlob.exp()); // Wrapped Import Key Blob
KMArray.cast(cmd).add((short) 1, KMByteBlob.exp()); // Auth Tag
KMArray.cast(cmd).add((short) 2, KMByteBlob.exp()); // IV - Nonce
KMArray.cast(cmd).add((short) 3, KMByteBlob.exp()); // Wrapped Key ASSOCIATED AUTH DATA
KMArray.cast(cmd).add((short) 4, KMInteger.exp()); // Password Sid
KMArray.cast(cmd).add((short) 5, KMInteger.exp()); // Biometric Sid
```

AES-GCM復号成功後、アプレット内で `AUTH_DATA`、つまり `wrappedKeyDescription` をASN.1解析して `keyFmt` と `KEY_PARAMETERS` を作る。

```java
KMAsn1Parser asn1Decoder = KMAsn1Parser.instance();
short keyFmt = asn1Decoder.keyFormatFromKeyDescription(data[AUTH_DATA]);
data[KEY_PARAMETERS] =
    asn1Decoder.parseAndUpdateAuthorizationList(
        data[AUTH_DATA], scratchPad, (short) 0, passwordSid, biometricSid);
data[ORIGIN] = KMType.SECURELY_IMPORTED;
importKey(apdu, keyFmt, scratchPad);
```

`parseAndUpdateAuthorizationList()` は `USER_SECURE_ID` を特別扱いし、以下のように置換する。

- `PASSWORD` の場合: `passwordSid`
- `FINGERPRINT` の場合: `biometricSid`
- `ANY` の場合: `passwordSid`
- それ以外、または不正な長さ: `INVALID_DATA`

この変更により、インポート鍵の認証制限はStrongBox内で、暗号的に認証済みのKeyDescriptionから構築される。

## 脆弱性の根本原因

根本原因は、StrongBoxアプレットが `importWrappedKey` の重要な鍵属性、特に `keyFormat`、`AuthorizationList`、`USER_SECURE_ID` 変換を、StrongBox外のHAL/ホストで処理された値として受け入れていたこと。

StrongBoxの設計上、Android OSやHALはStrongBoxより低い信頼境界にいる。したがって、鍵の使用制限を決める情報は、StrongBox内で、暗号的に保護された入力から導出されるべきだった。修正前はこの境界が曖昧で、制限されるべき鍵が正しくSIDへ束縛されない、またはホスト側で解釈された制限情報をアプレットが信じる構造になっていた。

## どういう脆弱性だったか

`importWrappedKey` でインポートされる鍵は、本来 `wrappedKeyData` 内の `KeyDescription` に含まれるAuthorizationListに従い、必要ならユーザーのPassword SIDやBiometric SIDに束縛される必要がある。

修正前は、アプレットが `KeyDescription` を自分で解析せず、HALがパースした `authList` / `keyFormat` をAPDU引数として受け取って鍵を作っていた。このため、鍵の制限情報がStrongBox内で暗号的に検証された形で適用されず、`USER_SECURE_ID` も実SIDに正しく置換されなかった。

結果として、認証やSIDにより制限されるべきインポート鍵のアクセス制御が弱まり、ローカル攻撃者が制限されるべき鍵を利用できる可能性がある。公開CVE説明の「restricted keys」「local information disclosure」は、制限付き鍵の誤ったインポート・利用により、本来認証後にのみ復号/署名等に使えるべき鍵が不適切に使われる状況を指していると判断した。

## 面白い点・調査メモ

- Android BulletinではGoogle/NXP/STMicroelectronics/Thalesの各StrongBox行に同じCVEが出ている。今回の対象はGoogle行 `A-434039170` のみ。
- 公開OSV/NVDの詳細は、初回公開時点の「StrongBoxにHigh severity」から、後で `KMKeymasterApplet.java` / `importWrappedKey` / `Improper Input Validation` へ詳細化されている。
- Google側の修正は `platform/external/libese` に公開されており、Pixelファームウェアのバイナリ解析は不要だった。
- コミットメッセージ自体に「KeyDescription is cryptographically bound to the encrypted wrapped key」「parsing it within the applet after successful decryption ensures greater security and integrity」とあり、修正意図がかなり直接的に書かれている。
- 追加コミット `04471a86e0d3dd4c7340f57f866ce1d2589db00f` で、`parseAndUpdateAuthorizationList()` のテストが追加されている。`USER_SECURE_ID` がPassword SID / Fingerprint SIDへ置換されること、不正タグや順序違反が拒否されることを検証している。

## 付帯ファイル

- `analysis/ASB-A-434039170.json`: Android OSVの元JSON
- `analysis/NVD-CVE-2025-48651.json`: NVD APIの元JSON
- `analysis/0556b32-refine-importWrappedKey.patch`: A-434039170対応の主要パッチ
- `analysis/04471a8-asn1-parser-tests.patch`: ASN.1 KeyDescription parserテスト追加
- `analysis/KMKeymasterApplet_before_0556b32.java`: 修正前アプレット実装
- `analysis/KMKeymasterApplet_after_0556b32.java`: 修正後アプレット実装
- `analysis/JavacardKeyMintDevice_before_0556b32.cpp`: 修正前HAL実装
- `analysis/JavacardKeyMintDevice_after_0556b32.cpp`: 修正後HAL実装
- `analysis/IKeyMintDevice_importWrappedKey_spec.aidl`: KeyMint importWrappedKey仕様
- `analysis/IKeyMintDevice_importWrappedKey_excerpt.txt`: 仕様の該当抜粋
- `analysis/libese-git-log-relevant.txt`: 関連コミットログ