if (mOwner) {
    // If the size is going to zero, just release the owner's data.
    if (desired == 0) {
        freeData();
        return NO_ERROR;
    }

    // If there is a different owner, we need to take
    // posession.
    uint8_t* data = (uint8_t*)malloc(desired);
    // SNIP: Check if malloc succeeded
    binder_size_t* objects = nullptr;

    if (kernelFields && objectsSize) {
        objects = (binder_size_t*)calloc(objectsSize, sizeof(binder_size_t));
        // SNIP: Check if calloc succeeded

        // Little hack to only acquire references on objects
        // we will be keeping.
        size_t oldObjectsSize = kernelFields->mObjectsSize;
        kernelFields->mObjectsSize = objectsSize;
        acquireObjects();
        kernelFields->mObjectsSize = oldObjectsSize;
    }
    // SNIP: rpcFields handling for non-/dev/binder Parcels

    if (mData) {
        memcpy(data, mData, mDataSize < desired ? mDataSize : desired);
    }
    if (objects && kernelFields && kernelFields->mObjects) {
        memcpy(objects, kernelFields->mObjects, objectsSize * sizeof(binder_size_t));
    }
    // ALOGI("Freeing data ref of %p (pid=%d)", this, getpid());
    if (kernelFields) {
        // TODO(b/239222407): This seems wrong. We should only free FDs when
        // they are in a truncated section of the parcel.
        closeFileDescriptors();
    }
    mOwner(mData, mDataSize, kernelFields ? kernelFields->mObjects : nullptr,
           kernelFields ? kernelFields->mObjectsSize : 0);
    mOwner = nullptr;

    // SNIP: Allocation count tracking
    // SNIP: Assign data and objects to this object
} else if (mData) {
    // SNIP: Resize data owned by this instance of Parcel
} else {
    // SNIP: Allocate initial data for currently empty Parcel
}

return NO_ERROR;

[そのコメントが導入された時点](https://android.googlesource.com/platform/frameworks/native/+/53b6ffe5af3951e8784c451ef8c4ff19f3d6b196%5E!/)で、`closeFileDescriptors()` の呼び出しは `IPCThreadState::freeBuffer()`（上記のコードで `mOwner()` 関数ポインタを通じて呼び出される）から `continueWrite()` メソッドに移動されましたが、ロジックは以前と同じでした。結局のところ、`Parcel` は Android IPC の核となる部分であり、もしコア IPC が本来閉じてはいけないファイルディスクリプタを閉じていたとしたら、それは明らかな問題になるでしょう。

ここで重要な点に移ります。上記のコードはいつ使用されるのでしょうか？これは、Parcel クラスが Binder ドライバから受信したデータ（その時点では [`/dev/binder` `mmap`](https://cs.android.com/android/platform/superproject/main/+/main:frameworks/native/libs/binder/ProcessState.cpp;l=587-592;drc=187efe18e3de6258af0230198c881915cc695567) 内に存在し、書き込みができない（そのメモリに書き込もうとすると `SIGSEGV` が発生する））の所有権を移動するときに使用されます。つまり、`Parcel` が着信トランザクションデータ（[`onTransact()`](https://developer.android.com/reference/android/os/Binder#onTransact(int,%20android.os.Parcel,%20android.os.Parcel,%20int)) に渡される `data` 引数）または着信リプライ（すなわち、[`transact()`](https://developer.android.com/reference/android/os/IBinder#transact(int,%20android.os.Parcel,%20android.os.Parcel,%20int)) 呼び出しに `reply` 引数として渡された `Parcel` オブジェクト、`transact()` はその `Parcel` オブジェクト内に参照を設定します）のいずれかである場合です。

実際には、`if (mOwner)` ブロックに入る唯一のケースは、システムが[トランザクションデータを解放するために `setDataSize(0)` を呼び出す](https://cs.android.com/android/platform/superproject/main/+/main:frameworks/native/libs/binder/IPCThreadState.cpp;l=1483-1488;drc=187efe18e3de6258af0230198c881915cc695567)場合ですが、その場合でも `if (desired == 0)` に入り、早期リターンが発生します。正当なシステム使用中に「異なる所有者がいる場合、所有権を取得する必要がある」パスに入るケースはありません。

# 「所有権取得」パスのトリガー

以前のエクスプロイトの1つで、[`createFromParcel()` が、本来読み取るべき `Parcel` に対して `writeInt(0)` を実際に呼び出すことができるケース](https://github.com/michalbednarski/TheLastBundleMismatch#side-effects)を示しました。その修正により、`AccountManagerService` 内での `Intent` 以外の `createFromParcel()` メソッドの実行は防止されましたが、`createFromParcel()` から `writeInt(0)` へのパスはそのまま維持されました。

まとめると、[`PackageParser` 内には以下のコードがあります](https://cs.android.com/android/platform/superproject/main/+/main:frameworks/base/core/java/android/content/pm/PackageParser.java;l=7789-7795;drc=7d3ffbae618e9e728644a96647ed709bf39ae759):```java
final Class<T> cls = (Class<T>) Class.forName(componentName);
final Constructor<T> cons = cls.getConstructor(Parcel.class);

intentsList = new ArrayList<>(N);
for (int i = 0; i < N; ++i) {
    intentsList.add(cons.newInstance(in));
}

したがって、「所有権取得」パスをトリガーするには、`onTransact()` に `data` として渡された `Parcel` 上で任意の `readParcelable` 呼び出しが必要です。このエクスプロイトでは、以前別のエクスプロイトで使用した[同じパス](https://github.com/michalbednarski/LeakValue#putting-parcelables-in-system_server-and-retrieving-them)を利用しています。`readParcelable` 呼び出しによって `PackageParser$Activity.CREATOR.createFromParcel()` が呼び出され、さらにその中で `PooledStringWriter` の名前が読み取られ、コンストラクタが呼び出された後で `Parcel` データが終了します。そのため、`writeInt()` は Parcel を再割り当てする必要があり、これによって「所有権取得」パスに入ります。

ここで注意すべき点ですが、もしその時点で `Parcel` データが終了していなかった場合、`writeInt()` はデータをその場で上書きしようとします。データが `/dev/binder` の `mmap` でバックアップされている場合、これは `SIGSEGV` を引き起こします。

# ファイルディスクリプタサニタイザ

当初のアイデアは、「所有権取得」パスでファイルディスクリプタを閉じ、その後トランザクションの終了時に同じディスクリプタが再度閉じられるようにすることでした。しかし、その間に別のトランザクションで `system_server` 内に別のファイルディスクリプタを配置し、後で自分のファイルディスクリプタを取り戻すというものです。その時点でその FD は別のファイルを指していることになります。

これは古い AOSP バージョンを使用したエミュレータでは機能しましたが、より新しいバージョンで試したところ、[ファイルディスクリプタサニタイザ (FDSan)](https://android.googlesource.com/platform/bionic/+/refs/heads/main/docs/fdsan.md) によって阻止されました。

特に、[`android-14.0.0_r29` では FDSan のカバレッジが拡張され、`Parcel` 内の FD も対象となりました](https://android.googlesource.com/platform/frameworks/native/+/7772039cc5084247450f6113d9a18eca17f672aa%5E!/)。

実際、FDSan が Parcel をカバーした後は、`Parcel` が FD を含んでいる場合、`closeFileDescriptors()` 呼び出しに到達することすらできませんでした。その呼び出しの前には `acquireObjects();` の呼び出しがあります。これは `Binder` ハンドルへの参照を取得します（そのハンドルは後で同じ関数内の `mOwner()` 呼び出しによって解放されます）。しかし、`acquireObjects()` は [FD に FDSan タグを設定](https://cs.android.com/android/platform/superproject/main/+/main:frameworks/native/libs/binder/Parcel.cpp;l=175-178;drc=f4c9b48c19f1b040efb35932b322f47e7779cafe) も行います。```cpp
case BINDER_TYPE_FD:
    if (obj.cookie != 0) { // owned
        FdTag(obj.handle, nullptr, who);
    }

つまり、二重の`FdTag`（古いタグを指定したままタグを閉じたり変更したりしない）はFDSanエラーを引き起こし、プロセスが中断されます。そして、まだ`closeFileDescriptors()`呼び出しに到達していません。「所有権取得」パスは通常の使用ではデッドコードであるため、このような問題は見過ごされる可能性があります

しかし、`if (obj.cookie != 0)`条件があります。これが偽の場合、`Parcel`内に存在するFDはその`Parcel`によって実際には所有されていないことを意味し、その`Parcel`が存在する限りFDを開いたままにしておくのは`Parcel`ユーザーの責任です。ただし、この`Parcel`はカーネルから来たばかりなので、`cookie`値は実際には元のプロセスからのものであり、`Parcel`が実際に`mOwner`を持っている場合には無関係と見なされます。しかし、「所有権取得」パスは実際にはそれを考慮せず、`cookie`値をそのままコピーします

これらをすべて合わせると、送信側で`cookie`値をゼロに設定することで、閉じられたファイル記述子を参照するが、それらを所有しているとは見なされず、再度閉じることもない`Parcel`を取得できます。これにより、FDSanをトリップするのを回避できますが、二重閉じの悪用経路も排除されます

# ParcelのJava側のトリック

そのようなFDは別の`Parcel`（さらに別のプロセス）に渡される可能性がありますが、このようなぶら下がりFDの作成をトリガーする方法は、リフレクションを介して`PooledStringWriter`を構築し、その後`ArrayList<IntentInfo>`に`add()`しようとすると`ClassCastException`がスローされるというものです

必要なこと:

* `onTransact()`に`data`引数として渡された`Parcel`の末尾にいること
* `PooledStringWriter`を構築し、その後Parcelはぶら下がりFDを持つが、`ClassCastException`もスローされる
* `system_server`内でリークさせたいFDが割り当てられるのを待つ
* その`Parcel`からのFDが、私たちのプロセスに送信される別の`Parcel`にコピーされる

これらの要件をすべて満たすために、新旧両方のトリックの一部を使用する必要があります

## 古いトリック

まずは古いトリックを再確認しましょう。それらのほとんどは、私の[`LazyValue`-using-`Parcel`-after-`recycle()` exploit](https://github.com/michalbednarski/LeakValue)ですでに説明されています

1. [`RemoteViews`クラスは、`Parcel.ReadWriteHelper`が設定された状態で、含まれている`Bundle`の逆シリアル化を実行します](https://cs.android.com/android/platform/superproject/main/+/main:frameworks/base/core/java/android/widget/RemoteViews.java;l=2287-2300;drc=9b2e54f25456f2726ab1a15e6b6dc19395a3b5b4)。[`ReadWriteHelper`が設定されている場合、`Bundle`は遅延ではなく先読みで逆シリアル化されます](https://cs.android.com/android/platform/superproject/main/+/main:frameworks/base/core/java/android/os/BaseBundle.java;l=1886-1896;drc=e1841f84f41213879e1f1b45ad4300b96970e545)。また、この時点で注意すべき点として、`RemoteViews`内のその`Bundle`に含まれるすべての`Bundle`も、直接`RemoteViews`内にあるものだけでなく、先読みで逆シリアル化されます
2. [`system_server`内で`Bundle`を逆シリアル化中に`BadParcelableException`がスローされた場合、その`BadParcelableException`は静かにキャッチされ、`Bundle`の内容はクリアされます](https://cs.android.com/android/platform/superproject/main/+/main:frameworks/base/core/java/android/os/BaseBundle.java;l=479-485;drc=efb735f4d5a2f04550e33e8aa9485f906018fe4e)。ただし、`createFromParcel`内での書き込みトリガーは`ClassCastException`をスローするため、ここではキャッチされないことに注意してください
3. [`ParceledListSlice`クラスは、逆シリアル化中にシリアル化データで指定されたオブジェクトに対してブロッキング発信Binder呼び出しを行います](https://cs.android.com/android/platform/superproject/main/+/main:frameworks/base/core/java/android/content/pm/BaseParceledListSlice.java;l=95-102;drc=e220b578ebc0885a28b83c95cb9ec78581bd8364)。これを使用して逆シリアル化の実行を停止させることができます

これらはすべて今必要ですが、それだけではありません

## 新しいトリック

[AIDLはRPCインターフェース実装を生成するためのツールですが](https://developer.android.com/guide/components/aidl)、それに加えて`Parcelable`構造の実装も生成できます

これらの構造は長さプレフィックス付きであるため、同じ構造の異なるバージョンは、途中にフィールドが追加されない限り、システム内で互換性があります（つまり、一方のバージョンが他方のプレフィックスである場合、バージョンは互換性があります）

AIDLが[`ReceiverInfo`構造](https://cs.android.com/android/platform/superproject/main/+/main:frameworks/base/core/java/android/app/ReceiverInfo.aidl)に対して生成したコードを見てみましょう:```java
public final void readFromParcel(android.os.Parcel _aidl_parcel)
{
  int _aidl_start_pos = _aidl_parcel.dataPosition();
  int _aidl_parcelable_size = _aidl_parcel.readInt();
  try {
    if (_aidl_parcelable_size < 4) throw new android.os.BadParcelableException("Parcelable too small");;
    if (_aidl_parcel.dataPosition() - _aidl_start_pos >= _aidl_parcelable_size) return;
    intent = _aidl_parcel.readTypedObject(android.content.Intent.CREATOR);
    if (_aidl_parcel.dataPosition() - _aidl_start_pos >= _aidl_parcelable_size) return;
    data = _aidl_parcel.readString();
    if (_aidl_parcel.dataPosition() - _aidl_start_pos >= _aidl_parcelable_size) return;
    extras = _aidl_parcel.readTypedObject(android.os.Bundle.CREATOR);
    // SNIP: Other fields
  } finally {
    if (_aidl_start_pos > (Integer.MAX_VALUE - _aidl_parcelable_size)) {
      throw new android.os.BadParcelableException("Overflow in the size of parcelable");
    }
    _aidl_parcel.setDataPosition(_aidl_start_pos + _aidl_parcelable_size);
  }
}

// check specific to memory type
switch(type) {
    case SENSOR_DIRECT_MEM_TYPE_ASHMEM: { // channel backed by ashmem
        if (resource->numFds < 1) {
            ALOGE("Ashmem direct channel requires a memory region to be supplied");
            android_errorWriteLog(0x534e4554, "70986337");  // SafetyNet
            return nullptr;
        }
        // SNIP: Further validation for SENSOR_DIRECT_MEM_TYPE_ASHMEM
    }
    case SENSOR_DIRECT_MEM_TYPE_GRALLOC:
        // no specific checks for gralloc
        break;
    default:
        ALOGE("Unknown direct connection memory type %d", type);
        return nullptr;
}

native_handle_t *clone = native_handle_clone(resource);
if (!clone) {
    return nullptr;
}
native_handle_set_fdsan_tag(clone);

sp<SensorDirectConnection> conn;
int channelHandle = 0;
if (deviceId == RuntimeSensor::DEFAULT_DEVICE_ID) {
    // SNIP: usual case where sensor belong to this device (not app streaming)
} else {
    auto runtimeSensorCallback = mRuntimeSensorCallbacks.find(deviceId);
    if (runtimeSensorCallback == mRuntimeSensorCallbacks.end()) {
        ALOGE("Runtime sensor callback for deviceId %d not found", deviceId);
    } else {
        int fd = dup(clone->data[0]);
        channelHandle = runtimeSensorCallback->second->onDirectChannelCreated(fd);
    }
}
// SNIP: Return connection

`dup(clone->data[0])` 呼び出しがあります。`clone` はリモートプロセスから受信した `native_handle_t` です。ネイティブハンドルは、データ内に特定の数のFDと特定の数のプレーン整数を含みます。その数は、`data` にアクセスする前に、[`numFds` と `numInts` を確認](https://cs.android.com/android/platform/superproject/main/+/main:system/core/libcutils/include/cutils/native_handle.h;l=37-38;drc=efb735f4d5a2f04550e33e8aa9485f906018fe4e) してユーザーがチェックする必要があります。

ここには「メモリタイプ固有のチェック」セクションもあります。これは、`SENSOR_DIRECT_MEM_TYPE_ASHMEM` の場合にここでチェックされることを確認し、`SENSOR_DIRECT_MEM_TYPE_GRALLOC` の場合、ネイティブハンドルの形式はデバイス固有であり、ここでは検証できないことを示しています。問題は、ランタイムセンサーのタイプは常に `SENSOR_DIRECT_MEM_TYPE_ASHMEM` として扱われることですが、その場合、`SENSOR_DIRECT_MEM_TYPE_GRALLOC` を指定して検証をバイパスできることです。

ただし、このコードに到達できるのは、「ランタイムセンサー」が存在する場合のみです。それが実際にどのような場合に発生するのか確信はありませんが、ユーザーが「Nearby app streaming」を使用する場合だと思います（？）

ただし、テストのために、[`VirtualDevice`](https://developer.android.com/reference/android/companion/virtual/package-summary) の登録を可能にする小さなクラスを追加しています。次のように使用できます```sh
adb shell 'CLASSPATH=$(pm path com.example.thisseemswrong | cut -d: -f2) app_process / com.example.thisseemswrong.VirtualDeviceReg'