AI支援プロジェクト。 この研究、エクスプロイト開発、およびドキュメントは、 モデル GLM-5.3 と DeepSeek V4.1 Flash を使用したAI支援によって作成されました。

amazon-mustang-hack

最終ファームウェア — Fire OS 7.3.3.1、PS7331.4463N、カーネル 4.9.117（ビルド 2025-05-03、SPL 2024-08-01） における Amazon Fire 7 第9世代（mustang、MT8163、Mali-T720） のルートエクスプロイト研究。

目標: LineageOS。このユニットではブートローダーパスは死んでいる（パッチ済みブートROM — CMDショートによるpreloaderのみ）ため、 残された唯一の経路はソフトウェアカーネルエクスプロイトである。

クイックスタート```

one-shot: build, run the exploit (retries across the probabilistic reclaim),

install a setuid-root su and verify it as an unprivileged user

nix-shell -p android-tools --run './run.sh' # add -p zig too if no zig

成功時:```
/data/metrics/su id     # run a command as root
/data/metrics/su        # interactive root shell

reclaim はおよそ 3 回に 1 回の起動で成功し、失敗するとタブレットはパニック/再起動します。 run.sh は再起動を待ってリトライするだけです。SELinux はエクスプロイトの一環として 強制的に Permissive にされるため、root は 実行時のみ です — 再起動すると ストック状態に戻り、run.sh を再実行する必要があります。

ビルド済みの st3 と su (armv7 静的) がコミットされているため、実行に ツールチェーンは不要です。zig があれば ./run.sh --build で poc/*.c から 再ビルドできます。

以下はすべてモデルが行った作業のログであり、以下に人間の入力はありません。

主要ターゲット (セッション 5 以降): kbase CVE-2022-38181 — ステージ 2 実証済み

GhostLock (下記) は保留中です: MTK の BUG_ON rtmutex 変種 + シェルからの カーネルアドレス開示ゼロ = このビルドではアーキテクチャ上の行き止まり (セッション 2-4)。 kbase JIT UAF は再診断され (destroy-worker の「無条件パニック」は JIT_FREE の 逆参照であり、ログはパニック途中の adbd 死亡により失われた)、ステージ 2 は 現在オラクル実証済みです — SESSION 5 のセクションを参照。

保留中: GhostLock, CVE-2026-43499

rtmutex remove_waiter() futex-PI スタック UAF (NebuSec 開示 2026-07、修正 3bfdc63936dd は 2026-04 に着地)。脆弱な範囲 2.6.39–7.1 → 我々の 4.9.117 (2025 年 5 月) は影響を受ける。

我々の正確なビルドで検証済み:

• CONFIG_FUTEX=y、rtmutex はコンパイル済み、バグはそのまま存在: rtmutex.c:1108-1111 は current->pi_lock/current->pi_blocked_on を使用 (本来は waiter->task であるべき); バグのある呼び出し箇所 rtmutex.c:1723 (rt_mutex_start_proxy_lock エラーパス)
• トリガー面 = 純粋な futex システムコール (WAIT_REQUEUE_PI/CMP_REQUEUE_PI)、デバイスノード不要、 SELinux でゲートされるものは何もない — kbase パスの致命的な障害はここには存在しない
• コンシューマ: sched_setattr → __sched_setscheduler → rt_mutex_adjust_pi(p) が sched/core.c:4706 で — 古い pi_blocked_on を逆参照 ✓
• プロキシ waiter は waiter スレッド自身のスタック上に存在 (futex.c:1975 が this->rt_waiter を渡し、 これは futex.c:2880 の futex_wait_requeue_pi で宣言) → waiter は arm32 select (nr 142) fd_sets を 通じて自身の解放済みフレームを刻印する
• エクスプロイト環境: KASLR なし (固定ベース 0xc0008000)、PAN なし、DEBUG_RT_MUTEXES オフ → コンパクトな 48 バイト rt_mutex_waiter (tree_entry@0, pi_tree_entry@0xc, task@0x18, lock@0x1c, prio@0x20, deadline@0x28)
• 最小チェーン: 2 つの書き込みスロット → modprobe_path @ 0xc111488c (文字列は vmlinux 内で自己位置特定; KALLSYMS_ALL オフのためデータシンボルにはこのトリックが必要) → 未知の binfmt exec → root スクリプト (setenforce 0, OTA 無効化, su)
• refs/ 内の参照: NebuSec/CyberMeowfia (オリジナル)、GhostLock-5.10 (Fire OS 8 移植、 src/exp32/ に完全な 32 ビット ARM トリガー)、ghostlock-...-4.19-k40 (Qualcomm 4.19 Android 移植)

TODO (移植計画)

1. トリガーを書く (3 スレッド requeue-PI デッドロック、コア 0-3) — exp32/main.c の移植
2. スタンプ形状: rt_waiter フレームオフセット vs do_sys_select fd_set 領域 — 我々の vmlinux を 逆アセンブル (do_sys_select の stack_fds vs futex_wait_requeue_pi フレーム)、 STAMP_NFDS/STAMP_WAITER_OFF を調整可能パラメータとして公開
3. arm32 48 バイト waiter 用の偽ライターエンコーディング → 「ADDR に V を書き込む」スロット
4. 2 スロット → modprobe_path、発火、root スクリプト
5. select-stamp が届かない場合のフォールバック: setsockopt(MCAST_JOIN_SOURCE_GROUP) スタンプ

ステータス

• Bootrom (amonet ハードウェア方式) — このユニットではパッチ済み、行き止まり
• mtk-su (CVE-2020-0069) — パッチ済み、Failed critical init step 3
• 攻撃面調査 — /dev/mali0 ワールド RW + SELinux gpu_device、kbase r26p0-01rel0
• CVE-2022-38181 を正確なビルドのソースで確認; ステージ 1 トリガーは動作
• CVE-2026-43499 (GhostLock) は検証済みだがブロック: MTK BUG_ON rtmutex 変種 + シェルからのカーネルアドレス開示なし (セッション 2-4)
• CVE-2022-38181 ステージ 2 実証済み (セッション 5): destroy-worker パニックは 誤診断だった; スプレー領域への UAF リダイレクト、オラクル検証済み
• ステージ 1: トリガー + スタンプ + コンシューマ (クラッシュ = チェーン稼働)
• ステージ 2 (kbase パス): スプレー領域への UAF リダイレクト — セッション 5 で実証済み
• ステージ 2b: 生バイトスロット制御 (xattr スタンプチャーン) → unlink 書き込み
• ステージ 3: 任意カーネル関数呼び出し → ROOT (セッション 10) — nf LOCAL_OUT フックハイジャック、selroot 2 パケットチェーン: selinux_state.enforcing をゼロ化、 偽エントリを commit_creds(&init_cred) に書き換え。uid=0、SELinux Permissive。
• [_] ステージ 4: root スクリプト (su, permissive, OTA オフ) + 永続化 — root 取得済み; 永続化はブロック (SESSION 11 参照): LK は verity-off/SELinux-permissive を eng/unlocked でゲートし、起動時再エクスプロイトには実行可能な実行者がいない。次: LK/amzn_verify_unlock のリバース。
• ステージ 5: カスタム OS ブートチェーン

主要な発見

デバイス / ファームウェア

• モデル KFMUWI、デバイス mustang、Fire OS 7.3.3.1 PS7331.4463N/0031575863040
• カーネル 4.9.117-g08fe75b-dirty、ビルド日時 Sat May 3 01:25:15 UTC 2025 (Linaro GCC 6.3-2017.05)
• Amazon は 2025 年 5 月に 7.3.3.1 をサイレントに再発行 (新しいインクリメンタル、同じバージョン文字列)
• 2020 年以降のリビジョンの Bootrom: eMMC CMD の GND 短絡で preloader のみ が得られる (パッチ済み)
• /dev/kb、/dev/dkb (Amazon カーネルバックアップパーティション) root:drmrpc 0660 — ロック済み

CVE-2022-38181 が適用される理由

• ドライバ: mali_kbase r26p0-01rel0 (Midgard, Mali-T720)、NVD の影響範囲 r4p0–r31p0 内
• Amazon の 2025 年 5 月の再ビルドは 2018 年のバグをそのまま出荷 — バックポートなし
• 正確な脆弱コード、ソース検証済み:
  • mali_kbase_mem.c:2721 kbase_jit_destroy_worker が領域を解放、kctx->jit_alloc[id] を決してクリアしない
  • mali_kbase_softjobs.c:1270 kbase_jit_free_finish が古い jit_alloc[ids[j]] を逆参照
  • mali_kbase_mem.c:3138 kbase_jit_backing_lost → destroy パス (reclaim 中に発火)

エクスプロイト環境 (すべてライブ config ダンプ + OTA vmlinux から検証済み)

• armv7 32 ビット、非 LPAE → KASLR なし (カーネルは固定 0xc0008000 VA / 0x40080000 PA)
• ARM_SW_DOMAIN_PAN なし → ret2usr が可能; CONFIG_PANIC_ON_OOPS=y (失敗した試行 = 再起動)
• SLAB_FREELIST_RANDOM/HARDENED なし、CONFIG_USER_NS/USERFAULTFD/NF_TABLES なし
• CONFIG_MODULES=y、STATIC_USERMODEHELPER なし → modprobe_path 上書き = root
• 1 GB RAM → 直接 reclaim (eviction に必要) は簡単に到達可能; ~1 GB 超のプレッシャーは カーネル自体をパニックさせる (無関係な lowmem/OOM バグ) — スプレーは ≤ 900 MB に保ち、~700 MB を使用

PoC 開発中に遭遇した UAPI の癖 (r26p0, _IOC_TYPE 0x80)

• MEM_ALLOC union は 32 バイト (in は extent を含む 4 × u64)
• フラグには BASE_MEM_PROT_GPU_RD|WR (ビット 2|3) を含める必要があり、レガシーな R|W ではない
• 任意の alloc の前に tracking-page mmap が必須: mmap(fd, offset=3<<12, PROT_NONE)
• JOB_SUBMIT のストライドは sizeof(base_jd_atom_v2) = 48 と等しくなければならない (base_jd_prio/base_jd_dep_type は u8 typedef)
• JIT: MEM_JIT_INIT (nr 14, v2 構造体)、alloc/free は JOB_SUBMIT 経由の ソフトジョブ (BASE_JD_REQ_SOFT_JIT_ALLOC=0x209, ...FREE=0x20a; jc=ユーザーポインタ, nr_extres=カウント)
• JIT alloc の結果はカーネルが info->gpu_alloc_addr を通じて書き込む (事前に確保して渡す必要がある GPU VA)

ステージ 1 の差分 (バグが発火することの証明)

退避可能オブジェクト	プレッシャー	結果
なし	900 MB	生存
なし	1300 MB	パニック (システム lowmem バグ — 無関係)
通常領域 + DONT_NEED	700 MB	生存
JIT 領域 + DONT_NEED	700 MB	reclaim パスでパニック

パニックは eviction 自体の間に発生する (evictable_reclaim_scan_objects → backing_lost → destroy worker) — ぶら下がり参照 (jit_alloc[]、evict リスト) は、我々が JIT_FREE を submit する前に走査される。ステージ 2 はレースに勝つ必要がある: プレッシャーがまだ 実行中の間に、解放された kbase_va_region を我々自身の MEM_ALLOC スプレーで再確保する。

成果物

• poc/stage2.c — ステージ 2 エクスプロイト (モード: step/uaf/spstep/spfree/spray/keys) — spray 700 = 完全オラクル実行; 生存して一時停止 (クリーンアップには kill)
• poc/mustang_jit_uaf.c — ステージ 1 PoC (モード: jit N / control N / pressure N)
• poc/build.sh — zig クロスビルド (静的 musl armv7)
• kernel/vmlinux — 正確な OTA ビルドから復元したシンボル (vmlinux-to-elf)
• kernel/config-* — 実行中デバイスからの /proc/config.gz ダンプ
• ksrc/ — Amazon OSS ソース (platform.tar + 展開済み midgard-r26p0 ツリー)
• OTA: /tmp/opencode/mustang_ota.bin (sha256 6068515a… は fireos-archive と一致) および 2.2 GB のカーネルソース tarball を ~/Desktop/amazon-mustang/ に保管
• ソースツリーパス: ksrc/kernel/mediatek/mt8163/4.9/drivers/misc/mediatek/gpu/gpu_mali/mali_midgard/midgard-r26p0/