AI 辅助项目。 本研究、漏洞利用开发及文档均借助 AI 辅助完成，使用了 GLM-5.3 和 DeepSeek V4.1 Flash 模型。

amazon-mustang-hack

针对 Amazon Fire 7 第 9 代（mustang，MT8163，Mali-T720） 最终固件——Fire OS 7.3.3.1，PS7331.4463N，内核 4.9.117（构建于 2025-05-03，SPL 2024-08-01）——的 root 漏洞利用研究。

目标：LineageOS。该设备的引导加载程序路径已失效（bootrom 已修补——仅能通过 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 次，失败会导致平板 panic/重启； run.sh 只是等待重启并重试。SELinux 在漏洞利用过程中被强制设为 Permissive，因此 root 是仅运行时有效——重启会恢复原厂状态，你需要重新运行 run.sh。

预编译的 st3 和 su（armv7 静态）已提交，因此运行无需工具链。如果你有 zig，./run.sh --build 会从 poc/*.c 重新构建它们。

以下内容只是模型工作日志，没有人类输入。

主要目标（自 session 5 起）：kbase CVE-2022-38181 — stage 2 已证实

GhostLock（见下文）已搁置：MTK 的 BUG_ON rtmutex 变体 + shell 无法泄露任何内核地址 = 在此构建上架构性死路（sessions 2-4）。 kbase JIT UAF 被重新诊断（destroy-worker 的“无条件 panic”其实是 JIT_FREE 解引用，日志因 adbd 在 panic 中途死亡而丢失），stage 2 现在已由 oracle 证实——见 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 已编译进内核，bug 原样存在： rtmutex.c:1108-1111 使用了 current->pi_lock/current->pi_blocked_on（应为 waiter->task）；有 bug 的调用点 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（移植计划）

编写触发（3 线程 requeue-PI 死锁，核心 0-3）——移植 exp32/main.c
标记几何：rt_waiter 帧偏移 vs do_sys_select fd_set 区域——反汇编我们的 vmlinux（do_sys_select stack_fds vs futex_wait_requeue_pi 帧），将 STAMP_NFDS/STAMP_WAITER_OFF 暴露为可调参数
针对 arm32 48 字节 waiter 的 fake-writer 编码 → “写 V 到 ADDR”槽
2 个槽 → modprobe_path，触发，root 脚本
如果 select-stamp 无法触及的备选方案：setsockopt(MCAST_JOIN_SOURCE_GROUP) 标记

状态

关键发现

设备 / 固件

型号 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 年的 bug——没有 backport
确切漏洞代码，源码验证：
- 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 期间触发）

利用环境（全部从实时配置转储 + 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（驱逐所需）轻易可达；压力 >~1 GB 会自行导致内核 panic（无关的 lowmem/OOM bug）——保持喷射 ≤ 900 MB，使用 ~700 MB

PoC 开发中遇到的 UAPI 怪癖（r26p0，`_IOC_TYPE 0x80`）

MEM_ALLOC 联合体为 32 字节（in 有 4 × u64，包括 extent）
flags 必须包含 BASE_MEM_PROT_GPU_RD|WR（位 2|3），而非旧版 R|W
任何分配前必须 mmap tracking-page：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 结构），分配/释放是软作业，通过 JOB_SUBMIT （BASE_JD_REQ_SOFT_JIT_ALLOC=0x209，...FREE=0x20a；jc=用户指针，nr_extres=计数）
JIT 分配结果由内核通过 info->gpu_alloc_addr 写入（你必须预先分配并传入的 GPU VA）

Stage-1 差分（证明 bug 触发）

可驱逐对象	压力	结果
无	900 MB	存活
无	1300 MB	panic（系统 lowmem bug——无关）
普通区域 + DONT_NEED	700 MB	存活
JIT 区域 + DONT_NEED	700 MB	在 reclaim 路径中 panic

Panic 发生在驱逐本身期间（evictable_reclaim_scan_objects → backing_lost → destroy worker）——悬空引用（jit_alloc[]、驱逐列表）在我们提交 JIT_FREE 之前就被遍历了。Stage 2 必须赢得竞态：在压力仍在运行时，用我们自己的 MEM_ALLOC 喷射重新分配已释放的 kbase_va_region。

产物

poc/stage2.c — stage-2 漏洞利用（模式：step/uaf/spstep/spfree/spray/keys） — spray 700 = 完整 oracle 运行；存活并暂停（kill 以清理）
poc/mustang_jit_uaf.c — stage-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/

构建与运行```

nix-shell -p zig --run 'zig cc -target arm-linux-musleabihf -static -O2 -o juaf poc/mustang_jit_uaf.c' adb push juaf /data/local/tmp/juaf && adb shell chmod 755 /data/local/tmp/juaf adb shell /data/local/tmp/juaf jit 700 # full trigger (~reboots device) adb shell /data/local/tmp/juaf control 700 # no-JIT control adb shell /data/local/tmp/juaf pressure 700 # raw memory-pressure control

## 参考资料

- GHSL-2022-054 安全公告：https://securitylab.github.com/advisories/GHSL-2022-054_Arm_Mali/
- Mo 的 Pixel 6 漏洞利用文章：https://github.blog/2023-01-23-pwning-the-all-google-phone-with-a-non-google-bug/
- Fire HD 10 (trona) 先例，同一漏洞家族：ericpardee.github.io/fire-hd-ownership
- Amazon 开源门户：amazon.com gp/help/customer/display.html nodeId=200203720
- XDA 解锁帖（对此硬件版本已失效）：xdaforums.com/t/fire-7-2019-mustang-unbrick-downgrade-unlock-root.3944365/


## 会话 3 附录（深度系统调用标记调查）

已测量的复制源深度（相对于系统调用入口 sp0 的绝对值；等待者范围为 -0x1d8..-0x1a8）：
- sendto sockaddr @ -0xc4 | process_vm iov @ -0x104 | recvmsg iov @ -0x11c
- sendmsg iov @ -0x12c | recvmmsg iov @ -0x154 | select fds @ -0x174
- pselect6 fds @ -0x19c | **sendmmsg iov @ -0x1bc（最佳 — 距 waiter+0x00 仅差 0x1c）**
- poll entries @ -0x3e0（完全在下方；错误一侧）

amazon-mustang-hack

最受欢迎

amazon-mustang-hack

快速开始```

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

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

以下内容只是模型工作日志，没有人类输入。

主要目标（自 session 5 起）：kbase CVE-2022-38181 — stage 2 已证实

已搁置：GhostLock，CVE-2026-43499

TODO（移植计划）

状态

关键发现

设备 / 固件

为什么 CVE-2022-38181 适用

利用环境（全部从实时配置转储 + OTA vmlinux 验证）

PoC 开发中遇到的 UAPI 怪癖（r26p0，_IOC_TYPE 0x80）

Stage-1 差分（证明 bug 触发）

产物

构建与运行```

PoC 开发中遇到的 UAPI 怪癖（r26p0，`_IOC_TYPE 0x80`）