CVE-2026-43655: AppleM2ScalerCSCDriver 共有スケジューラの use-after-free

CVE-2026-43655 に関する公開技術情報です。AppleM2ScalerCSCDriver / IOSurfaceAccelerator の use-after-free であり、特別な entitlements を必要とせず、デフォルトの iOS アプリサンドボックスから到達可能です。

Apple はこの問題を iOS 26.5 / iPadOS 26.5 / macOS Tahoe 26.5 で修正しました。このリポジトリには、Objective-C で書かれた概念実証 (PoC) ソース、最小限の entitlements、ビルド済み IPA、および影響を受けるデバイス上でこの問題を理解・再現するために必要な技術解説が含まれています。

概要

このバグは、スケーラースケジューラにおける破棄/ライフタイムのエラーです。ユーザープロセスは、非同期スケーラー操作を送信し、それらの操作を所有する IOSurfaceAcceleratorClient 接続を閉じ、ドライバ全体で共有されるスケジューラ構造体に古いエントリを残すことができます。その後のスケジューラパスは、すでに解放され再利用された操作ストレージを指すエントリを処理できます。

PoC は、2 つの異なるマーカー値を使用してライフタイムバグを実証します:

• 被害 (victim) 接続マーカー: 0xDEAD0001
• スプレー/置換接続マーカー: 0xBEEF0002

被害接続は非同期操作を送信してから閉じられます。その後、置換接続が開かれ、独自のマーカーを 0xBEEF0002 に設定します。次のスケーラー・スケジューリング・サイクルが実行されると、フォールトは被害マーカーではなく置換マーカー (x9 = 0x00000000BEEF0002) を観測します。これは、スケジューラが解放され、その後別の接続に再割り当てされた操作スロットから読み取ったことを証明します。

影響を受ける構成

• 影響を確認した OS: iOS 26.4
• 修正バージョン: iOS 26.5 / iPadOS 26.5 / macOS Tahoe 26.5
• Kext: com.apple.driver.AppleM2ScalerCSCDriver
• ユーザークライアントパス: IOSurfaceAcceleratorClient
• PoC が使用するアプリ entitlements: get-task-allow のみ
• 脱獄なし、プラットフォーム entitlement なし、Apple 専用のプライベート entitlement なし

根本原因

AppleM2ScalerCSCDriver は、スケーラークライアント間で共有されるスケジューラ状態を保持します。関連するライフタイムの不一致は次のとおりです:

1. クライアントが非同期スケーラー操作を送信する。
2. それらの操作は、スケジューラが所有する状態に挿入される。
3. クライアント接続が IOServiceClose で閉じられる。
4. クライアントごとの操作ストレージが解放される。
5. 共有スケジューラ状態から、閉じられたクライアントに属するエントリが完全には削除されない。
6. 後のスケジューラパスが古い操作ポインタを処理する。

破棄パスは、閉じられるクライアントの保留中のスケジューラエントリを共有スケジューラヒープから削除しません。スケジューラは後でそれらの古いポインタを通じてフィールドを読み書きします。

分析中に観測された重要なフィールド:

操作アロケータの動作により、このバグは観測可能になります: 解放された操作スロットは、後で別の接続からの操作によって再利用される可能性があります。被害接続を閉じてすぐに新しい接続をスプレーすることで、PoC は古いスケジューラエントリが現在スプレー接続が所有するメモリを指すようにできます。

x9 = 0xBEEF0002 が UAF を証明する理由

PoC は被害/スプレーの区別を使用します:

1. 被害接続がマーカー 0xDEAD0001 を設定する。
2. 被害接続が 50 個の非同期スケーラー操作を送信する。
3. 被害接続が閉じられ、被害操作オブジェクトが解放される。
4. スプレー接続がマーカー 0xBEEF0002 を設定する。
5. スプレー操作が解放された操作プールスロットを再利用する。
6. スケジューラが後で古い被害スケジューラエントリを処理する。

スケジューラがまだ有効な被害所有オブジェクトを読み取っていた場合、観測される値は 0xDEAD0001 になるはずです。代わりに、再現されたフォールトは 0xBEEF0002 (置換スプレー接続によって書き込まれた値) を観測します。これは、スケジューラが解放されて再利用されたカーネルメモリへの古いポインタを逆参照していることを示す重要な証拠です。

これはまた、接続間の影響を示しています: スケジューラエントリはある接続によって作成されましたが、後でスケジューラが触れたメモリは別の接続用にリサイクルされていました。再現した実行では、最終的なスケジューラアクティビティは、元の PoC プロセスではなく、通常の SpringBoard/コンポジタ/UI アクティビティによって駆動される可能性があります。

影響

• 解放済み/再利用された操作メモリからのカーネル読み取り。
• スケジューラの会計/状態更新中に、解放済み/再利用された操作メモリ内の固定オフセットへのカーネル書き込み。
• スケジューラヒープがスケーラーユーザー間で共有されるため、接続間での影響。
• スケーラースケジューリングを駆動する後続の任意のプロセスが古いエントリを処理させる可能性があるため、プロセス間でのトリガー動作。
• 古いスケジューラ状態は、元の PoC アプリの即時実行ウィンドウを超えて存続し、後のスケジューラサイクルでトリガーされる可能性があります。

Apple の公開アドバイザリでは、この影響は次のように説明されています: 「アプリがシステムの予期しない終了を引き起こしたり、カーネルメモリを読み取ったりする可能性があります。」

実機での再現手順

重要な再現の詳細: TEARDOWN UAF をタップした後、デバイスがすぐにパニックするとは限りません。PoC は最初に古いスケジューラ状態を準備します。このバグは次のスケーラー・スケジューリング・サイクルでトリガーされます。これは実際には SpringBoard/コンポジタのアクティビティがスケーラーを駆動したときに発生します。私の実機での再現では、PoC が古いスケジューラ状態の準備を終えた後、ダイナミックアイランド をタップ/操作してスケジューラサイクルをトリガーしました。

手順:

1. PoC を実行する前に、影響を受けるデバイスを再起動します。
2. ScalerTeardownUAF.ipa をインストールして起動します。
3. TEARDOWN UAF をタップします。
4. PoC が被害 AppleM2ScalerCSCDriver 接続を開きます。
5. PoC が送信元/宛先 IOSurface オブジェクトを作成します。
6. PoC が同期ベースラインスケーラー操作を送信します。
7. PoC がセレクタ 10 のクレジット/マーカーデータを被害接続上で 0xDEAD0001 に設定します。
8. PoC が被害接続上で 50 個の非同期操作を送信します。
9. PoC が IOServiceClose で被害接続を閉じ、被害所有の操作オブジェクトを解放します (古いスケジューラエントリは残ります)。
10. PoC が 50 個のスプレー接続を開きます。
11. 各スプレー接続がセレクタ 10 のクレジット/マーカーデータを 0xBEEF0002 に設定します。
12. PoC がスプレー接続上で追加の非同期操作を送信し、解放された操作スロットを再利用してスケジューラへの圧力を維持します。
13. アプリがトリガーを促したら、ダイナミックアイランド をタップ/操作して SpringBoard/コンポジタのアクティビティを発生させ、スケーラースケジューラを駆動します。
14. 古いスケジューラエントリが処理されると、デバイスはパニック/再起動します。
15. 再起動後、パニックレジスタ状態に x9 = 0x00000000BEEF0002 が含まれていることを確認します。

期待される証明条件:

• x9 = 0x00000000BEEF0002 は、スケジューラが解放された被害操作に元々属していたメモリからスプレーマーカーを読み取ったことを意味します。
• 0xBEEF0002 は被害マーカーではなく、置換接続マーカーです。
• したがって、観測されたスケジューラの読み取りは、解放と再利用の後に発生しました。

PoC の動作

含まれているソースは、次のシーケンスを実行します:

open victim connection
create IOSurface source/destination pair
submit sync baseline scaler request
set victim marker = 0xDEAD0001 through selector 10
submit 50 async scaler operations
close victim connection
open 50 spray connections
set spray marker = 0xBEEF0002 through selector 10
submit repeated async scaler operations on spray connections
wait for SpringBoard/compositor scheduler trigger

関連するソースファイルは ScalerTeardownUAF.m です。

ビルド

xcrun -sdk iphoneos clang -framework Foundation -framework UIKit -framework IOKit \
  -framework IOSurface -isysroot $(xcrun --sdk iphoneos --show-sdk-path) \
  -arch arm64 -arch arm64e -miphoneos-version-min=16.0 -fobjc-arc \
  -o iPhoneProbe.app/iPhoneProbe ScalerTeardownUAF.m
ldid -S entitlements.plist iPhoneProbe.app/iPhoneProbe
mkdir -p /tmp/pkg/Payload
cp -r iPhoneProbe.app /tmp/pkg/Payload/
cd /tmp/pkg && zip -qr ScalerTeardownUAF.ipa Payload

リポジトリのファイル

タイムライン

• AppleM2ScalerCSCDriver の動作をテスト中に最初のクラッシュを発見。
• 被害/スプレーマーカーの区別で UAF を証明: 被害 0xDEAD0001、スプレー 0xBEEF0002。
• ダイナミックアイランド / SpringBoard コンポジタのアクティビティを通じて次のスケーラー・スケジューリング・サイクルをトリガーし、実機での再現を確認。
• Apple は 26.5 リリースラインでこの問題を修正し、CVE-2026-43655 を割り当てました。