Amazon Fire TV Stick 3rd Gen（sheldonp）上的 CVE-2026-43499

将 Linux 内核提权链接到 preloader 降级与 bootloader 解锁。

概述

本仓库记录了我对 Amazon Fire TV Stick 3rd Gen（sheldonp）上 CVE-2026-43499 利用链的授权复现。该利用链使用临时内核 root 执行受控的 preloader 降级，然后使用现有的 Kamakiri BootROM 工作流进入已解锁的 fastboot 并完成 bootloader 解锁。

这是一次复现和针对特定设备的案例研究。我并未发现 CVE-2026-43499，未创建原始的 IonStack/GhostLock 漏洞利用，也未开发 Kamakiri。上游研究人员和开发者已在下方致谢。

[!IMPORTANT] 本文是一份技术记录，而非通用的 root 指南。构建兼容性很重要，临时 root 并非持久 root，涉及 Preloader、LK、TEE 或受 dm-verity 保护分区的错误操作可能会永久变砖设备。

复现记录

端到端利用链于 2026 年 9 月 12 日完成。本仓库记录了经过测试的设备与软件版本、所使用的确切归档文件、其 SHA-256 哈希值，以及过程中捕获的原始证据。

范围

不在范围内：漏洞发现、新的漏洞利用实现、远程利用、持久 root，或对除已测试 sheldonp 设备之外的其他设备的支持。本次复现期间未安装任何自定义 ROM。

复现归档文件

以下是本次复现期间使用的确切 ZIP 归档文件。这些归档文件不在本仓库中重新分发；其 SHA-256 哈希值已记录，以便将独立获取的副本与本案例研究中使用的文件进行比较。

这些哈希值标识了本案例研究中使用的副本；读者仍应将下载内容与原始上游来源进行比较，并查阅适用的第三方许可证。

技术背景

CVE-2026-43499，也称为 GhostLock，是 Linux 内核优先级继承 futex/rtmutex 路径中的一个释放后使用（use-after-free）漏洞。在代理锁回滚期间，remove_waiter() 操作的是 current，而不是存储在 waiter->task 中的任务。结果，实际等待者可能返回到用户空间时，pi_blocked_on 仍引用已释放内核栈帧中的 rt_mutex_waiter。

原始的 IonStack 研究将这一悬空栈引用转化为本地提权原语。R0rt1z2 将该技术适配到运行 Fire OS 7（基于 4.4 内核）的 Fire TV Stick 3rd Gen 和 Fire TV Stick Lite（sheldonp/sheldon）。

本案例研究的关键区别在于，CVE-2026-43499 并不直接解锁 bootloader。它提供临时的内核级访问权限。这种短暂的访问权限使得执行受控的 preloader 降级成为可能，而这是运行较旧的 Kamakiri BootROM 利用链之前所必需的。

利用链

flowchart LR
    A[Fire OS 7 on sheldonp] --> B[CVE-2026-43499 / GhostLock]
    B --> C[Temporary root shell]
    C --> D[Controlled preloader downgrade]
    D --> E[Expected non-booting transition state]
    E --> F[Kamakiri BootROM stage]
    F --> G[Unlocked fastboot]
    G --> H[Bootloader unlocked]

该利用链跨越两个独立的安全边界：

1. 内核边界： 一个非特权本地进程通过 GhostLock 获得临时 root 上下文。
2. 引导链边界： 临时 root 通过恢复兼容的 preloader，为设备准备一条已知的基于 BootROM 的解锁路径。

方法论

1. 建立基线

在更改设备之前，我通过 ADB 识别了硬件代号，并记录了 Fire OS、构建、bootloader 和内核版本。

adb devices -l
adb shell getprop ro.product.device
adb shell getprop ro.product.model
adb shell getprop ro.build.version.release
adb shell getprop ro.build.version.incremental
adb shell getprop ro.build.fingerprint
adb shell getprop ro.bootloader
adb shell uname -a
adb shell id

得到的基线为 sheldonp / AFTSSS、Fire OS PS7716.5666N、增量版本 0036005356164、Android 9 和内核 4.4.162+。序列号被有意省略。

2. 使用 GhostLock 获取临时 root

我通过 USB 连接 Fire TV，并启用 ADB 调试，使用 GhostLock 1.1.0，即随 R0rt1z2 XDA 指南发布的 sheldon/sheldonp 包。设备专用的启动器会重启 Fire TV 以从全新状态开始，部署漏洞利用，并在必要时重试。

成功利用会创建一个临时 root 环境。我从 ADB shell 验证了安全上下文，而不是仅将脚本完成视为证据：

adb shell
su
id

root 上下文是短暂的，重启后会丢失。这种行为很重要：此阶段是降级的使能原语，而不是最终的持久化机制或 bootloader 解锁本身。

成功运行显示 uid=0，将 SELinux 更改为临时环境的宽容模式，挂载了临时 su，并禁用了该工具处理的 Fire OS OTA 包。

完整的 GhostLock 漏洞利用跟踪 作为支持证据保留。

3. 降级 preloader

在临时 root 可用的情况下，我使用了该软件包专用的降级工作流，而不是手动写入固件分区。这恢复了与现有 Kamakiri 路径兼容的 preloader。

降级后，Fire TV 有意停止启动进入 Fire OS。在此特定工作流中，这种无法启动的状态是活动内核阶段与 USB BootROM 阶段之间预期的交接状态。绝不能将其与任意失败刷写可恢复的证明相混淆。

[!CAUTION] 切勿擦除 Preloader。不要随意写入 LK、TEE、Preloader、boot、recovery、system、vendor 或其他受保护分区。上游指南警告称，对关键固件的损坏可能导致永久硬砖，因为可能不再保留可用的恢复路径。

4. 运行 Kamakiri BootROM 利用链

用于此设备的 Kamakiri 工作流受 Linux 支持并有文档记录。因此，我启动了 Ubuntu Live 会话，并在其中执行了完整的解锁工作流，包括底层 USB BootROM 阶段，而未在主机上安装 Ubuntu。我未在 Windows 或 macOS 上测试此阶段。

使用解锁指南引用的 sheldon/sheldonp Kamakiri 包，过程如下：

1. 准备 Kamakiri 所需的 Python、PySerial、PyUSB、ADB、Fastboot 和 USB 环境。
2. 启动 bootrom-step.sh，并通过 USB 连接已关机的 Fire TV。
3. 等待 BootROM 阶段完成，并将设备转换到修改后的 fastboot 环境。
4. 运行 fastboot-step.sh 以完成解锁工作流。
5. 重启并验证预期的已解锁引导路径可用。

Kamakiri 将该设备识别为 sheldonp，完成了 RPMB 降级，刷写了利用链所需的 TZ/LK 组件，注入了 microloader，并强制设备进入其破解的 fastboot 模式。

归档文件哈希值和 Ubuntu 版本已记录在上方。读者应使用链接的上游指南获取特定版本的说明，而不是假设这些高层步骤适用于其他构建。

5. 验证结果

我将以下各项视为独立的里程碑，并为每一项捕获了证据：

6. 保留 Fire OS 并调整解锁后状态

我的目标是保留原厂 Fire OS，而不是立即安装自定义 ROM。在 TWRP 中，我避免擦除数据或替换操作系统，然后重启进入现有的 Fire OS 安装。TWRP 和已解锁引导路径保持可用，同时保留了原厂用户环境。

返回 Fire OS 后，我保持 OTA 更新禁用，以便 Amazon 无法悄悄将设备迁移到更改了漏洞利用或修改了已恢复引导链的构建。我还禁用了 Amazon 系统应用保护组件，在 Fire TV 社区工具中通常称为 ARCUS。这会改变 Amazon 的 OS 级应用阻止行为；它不会绕过 Widevine、订阅检查或单个应用程序内部实现的许可证强制执行。

可选的后续步骤

已解锁的 bootloader 和 TWRP 也使得安装兼容的自定义软件成为可能。该设备系列的一个社区选项是 基于 Android 13 的 LineageOS 20。其他兼容 ROM、恢复工作流或持久 root 配置也可能可行。

这些替代方案不属于本次复现的一部分。它们应被视为具有各自固件、TZ、数据擦除、DRM、内存和恢复考虑因素的独立过程。

观察

• 有线 USB ADB 连接更可取，因为漏洞利用重试可能会重启目标并中断无线 ADB。
• 漏洞利用可靠性取决于目标和构建。重试或重启并不能证明设备不受支持，但仍必须验证偏移量和构建兼容性。
• 临时 root 阶段和 Kamakiri 阶段解决不同的问题，应独立记录。
• 降级后预期的无法启动状态只有在降级工具报告成功且正在遵循确切受支持的工作流时才有意义。
• 脚本成功退出是比捕获的设备状态、root 身份和 fastboot/恢复验证更弱的证据。
• 解锁 bootloader 不需要替换 Fire OS；保留原厂 Fire OS 是解锁后的有意选择。
• 禁用 ARCUS 会影响 Amazon 的应用阻止层，而应用程序 DRM 和内容许可证仍是独立的问题。

安全影响

在存在漏洞且受支持的 Fire OS 构建上，已在设备本地运行的代码可以利用内核缺陷获得临时 root 上下文。在此实验中，该访问权限将攻击面扩展到正在运行的操作系统之外：它促成了固件降级，从而重新引入了较旧的 BootROM 漏洞可利用的引导链条件。

该利用链说明了为什么设备安全不仅仅取决于修补单一层。当特权软件可以修改安全关键固件状态时，内核提权可以成为通往更低层持久化或引导链攻陷的桥梁。

仓库结构

.
├── README.md              # Case study and methodology
├── LICENSE                # CC BY 4.0 for original documentation and media
├── images/
│   ├── README.md          # Evidence index and redaction guidance
│   └── evidence/          # Sanitized screenshots and photographs
└── references/
    └── README.md          # Source ledger and artifact guidance

本仓库不重新分发第三方 ZIP 归档文件。请从原始 XDA 指南获取它们，查阅其适用条款，并将其哈希值与上方记录的值进行比较。

致谢

• NebuSec / CyberMeowfia — CVE-2026-43499 的发现以及原始 IonStack/GhostLock 研究和漏洞利用实现。
• R0rt1z2 — Fire OS 适配、4.4 GhostLock 分支，以及 sheldon/sheldonp 临时 root 与降级指南。
• IonStackQuest3 — 首个面向 Linux 5.10 内核的公开 GhostLock 移植，由下游 Fire OS 项目致谢。
• Amonet/Kamakiri 贡献者，包括 xyz、k4y0z、Rortiz2、t0x1cSH，以及原始解锁帖中致谢的测试人员 — BootROM、fastboot、恢复和设备专用解锁工作。

我的贡献是独立复现、设备专用执行记录、对各阶段如何连接的分析，以及本仓库中发布的原始证据。

参考资料

维护中的来源台账位于 references/README.md。主要来源包括：

• CVE-2026-43499 记录
• NebuSec：GhostLock 漏洞条目
• NebuSec：IonStack 第三部分 — Android 利用
• CyberMeowfia：IonStack/CVE-2026-43499 源码
• R0rt1z2/GhostLock，4.4 分支
• XDA：sheldon/sheldonp 的临时 root 与 preloader 降级
• Amonet/Kamakiri 源码
• XDA：sheldon/sheldonp 的 bootloader 解锁、TWRP 与救砖指南
• Linux 内核针对 remove_waiter() 的修复

负责任使用声明

本材料仅供教育用途以及在您拥有或明确获准测试的硬件上进行授权安全研究。它不附带任何担保。您需对自己的行为所导致的合法合规、数据丢失、服务中断和硬件损坏负责。

许可证

为本仓库撰写的原创文本和图像根据 Creative Commons Attribution 4.0 International License 许可。

第三方工具、漏洞利用代码、固件、引用、截图、商标和引用材料仍受其各自作者身份和许可证约束。包含链接或致谢并不会将该材料重新许可为 CC BY 4.0。