CVE-2026-43499 · HONOR WIN RT (AAK-AN00) 一時的Root研究ノート

（全部deepseekが書いたもので、私は何もわかっていません）

デバイスのBootloaderは永久にロック（ro.oem_unlock.supportedが空）、fastbootなし、永続suなし、Magiskなし。 唯一残された道はカーネル脆弱性。本リポジトリは「攻撃可能かどうか」から「攻撃後にどれだけ安定するか」までの完全な過程を記録する。

性質：一時的なroot、再起動で無効。

免責事項

本リポジトリは、本人所有デバイス上で行ったセキュリティ研究の過程を記録するものであり、目的はカーネルPI競合の成因と安定性の境界を理解することにある。

• exploitバイナリや直接実行可能な攻撃ペイロードは一切含まない —— ペイロードとフレームワークは上流の公開プロジェクトに由来し、本リポジトリは参照するのみで再配布しない。
• 特定ベンダーのバイパス手段に関するチュートリアルは提供せず、非認可デバイスでの使用を推奨しない。
• リポジトリ内のオフセット、シンボルアドレスは本文に記載されたただ一つのカーネルbuildに対してのみ有効であり、カーネルが変わればすべて無効となる。
• 関連する欠陥はupstreamで修正済み（下記参照）。本文の長期的価値は「この記録そのもの」にある—— 現実の、非理想的な条件下での競合脆弱性の実戦振り返りであり、そのすべての不快な副作用を含む。

0. 一言で結論

唯一通り抜けられた経路は：

CVE-2026-43499（futex PI競合 write-what-where） + rt_sigreturn キャリア
  → LD_PRELOADでshellドメインプロセスに注入
  → 二段階式：まずSELinux Permissiveを攻撃、次にtask->real_cred / credをinit_credに変更
  → uid=0(root) context=u:r:kernel:s0、さらにsuデーモンを植え込む

しかし本当に書き残す価値があるのは「どうやってrootを取るか」ではない——取った後に起きることだ。

得られるのは安定したrootではなく、「いつでも起爆されうる状態」である。

exploitの書き込みプリミティブは偽造されたrt_mutex_waiterを本物のfutex PIチェーンに繋ぎ込み、 このwaiterのキャリアは後続のシステムコールで再利用されるカーネルスタック / スプレーページである。 ゆえにrootが着地した瞬間から、あらゆるシステムレベルのスケジューリングや優先度変更がそれを踏み、直接カーネルpanicで再起動しうる。 これはバグではなく、この攻撃手法の固有の代償である —— 詳細はdocs/03参照。

1. 適用境界（合致しなければ本方案全体が無効）

なぜカーネルバージョンを厳密に固定する必要があるか：欠陥は6.6.140で修正され、本機は6.6.118 < 6.6.140なのでまだ残っている； 同時にexploitのすべてのカーネルシンボルアドレスと「キャリア幾何」はこの一つのbuildに固定されており、カーネルが変わればオフセット表は即座に無効となり、かつ一般的にロールバック不可である。

2. 権限昇格経路の全景

┌─ 材料 ────────────────────────────────────────────────┐
│ boot.img + xbl_config.elf（デバイスファームウェアから抽出）│
│        ↓ シンボル解決                                   │
│ target.h（カーネルシンボルアドレス、kallsymsとバイト単位で照合済み）│
│        ↓ ビルド                                         │
│ preload.so ──► デバイス側 /data/local/tmp/*.so         │
└────────────────────────────────────────────────────────┘
                 ↓  LD_PRELOAD注入
     ┌──────────── 二段階式（必ず二つの独立プロセス）────────────┐
     │ 段階A  GW_SELINUX=1        → selinux_state.enforcing = 0   │
     │ 段階B  GW_CHAIN=1 RTSIG_TASK_INIT=1 GW_SU=1               │
     │         → task->real_cred ← &init_cred                      │
     │         → task->cred      ← &init_cred（「プリセットライター」プロセスが実行）│
     │         → setresuid(0,0,0) 正規化                           │
     │         → 内蔵su + daemonを植え込む                          │
     └─────────────────────────────────────────────────────────────┘
                 ↓
     uid=0(root) context=u:r:kernel:s0

必ず正しく行わなければならない三つの点（誤るとフリーズまたは直接panic）：

1. 順序の鉄則：先にreal_cred、後にcred。 逆順だと瞬時に全権限となり、スレッドが制御不能になる。
2. 二つの書き込みの間には必然的にcred ≠ real_credの過渡状態が存在する。 この時いかなるsched_setaffinityもEPERMとなる → 全体がフリーズ。 正解は最初の書き込みの前に「プリセットライター」プロセスをforkしておくこと（資格情報がクリーン）。親プロセスが最初の書き込みを行い、ライターが二番目の書き込みを行い、誰も過渡状態でsyscallを発行しない。
3. アドレスモデルはKASLRと無関係。 攻撃全体は線形マッピングエイリアスのみを通る alias(image) = PAGE_OFFSET | (image − KIMAGE_TEXT_BASE + Δ)、再起動を跨いで安定； いわゆる「slide段階」の真の価値は書き込みプリミティブの自己検証であり、KASLRの回避ではない。

上流フレームワーク：Linuxoid-cn/CVE-2026-43499-Poc-Analysis。 これはGhostLockではないことに注意 —— GhostLockはpselect経路を通り、本buildのwaiter着地点幾何と一致しない。 詳細はdocs/06参照。

3. ディレクトリ

4. タイムライン

5. 後進への一言

もしあなたもBLロックされた機種を攻撃しているなら、まずrootを取って何をするのかをはっきり考えてほしい。 なぜならこの種の機種ではrootはおそらく十数分しか使えないウィンドウだからだ。 「rootが必要で再起動を跨いで保持できる」操作をリストアップし、一度に全部実行し、その後rebootでクリーンな状態に戻す。 「副作用を消そう」としないこと —— それは手法そのものの代償である。