CVE-2026-43499 on Amazon Fire TV Stick 3rd Gen (sheldonp)

Chaining a Linux kernel privilege escalation into a preloader downgrade and bootloader unlock.

Overview

This repository documents my authorized reproduction of the CVE-2026-43499 exploitation chain on an Amazon Fire TV Stick 3rd Gen (sheldonp). The chain used temporary kernel root to run a controlled preloader downgrade, then used the existing Kamakiri BootROM workflow to reach unlocked fastboot and complete the bootloader unlock.

This is a reproduction and device-specific case study. I did not discover CVE-2026-43499, create the original IonStack/GhostLock exploit, or develop Kamakiri. The upstream researchers and developers are credited below.

[!IMPORTANT] This write-up is a technical record, not a universal rooting guide. Build compatibility matters, temporary root is not persistent root, and mistakes involving Preloader, LK, TEE, or dm-verity-protected partitions can permanently brick the device.

Reproduction record

The end-to-end chain was completed on September 12, 2026. This repository records the tested device and software versions, the exact archives used, their SHA-256 hashes, and original evidence captured during the process.

Scope

Out of scope: vulnerability discovery, a new exploit implementation, remote exploitation, persistent root, or support for devices other than the tested sheldonp unit. No custom ROM was installed during this reproduction.

Reproduction archives

The following are the exact ZIP archives used during this reproduction. The archives are not redistributed in this repository; their SHA-256 hashes are recorded so independently obtained copies can be compared with the files used in this case study.

These hashes identify the copies used in this case study; readers should still compare their downloads against the original upstream sources and review the applicable third-party licenses.

Technical background

CVE-2026-43499, also known as GhostLock, is a use-after-free in the Linux kernel's priority-inheritance futex/rtmutex path. During proxy-lock rollback, remove_waiter() operated on current instead of the task stored in waiter->task. As a result, the actual waiter could return to userspace with pi_blocked_on still referencing an rt_mutex_waiter in a released kernel stack frame.

The original IonStack research turns that dangling stack reference into a local privilege-escalation primitive. R0rt1z2 adapted the technique to the Fire TV Stick 3rd Gen and Fire TV Stick Lite (sheldonp/sheldon) running Fire OS 7 on a 4.4 kernel.

The key distinction in this case study is that CVE-2026-43499 does not unlock the bootloader directly. It provides temporary kernel-level access. That short-lived access makes it possible to perform the controlled preloader downgrade required before the older Kamakiri BootROM chain can run.

Exploit chain

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]

The chain crosses two separate security boundaries:

1. Kernel boundary: an unprivileged local process gains a temporary root context through GhostLock.
2. Boot-chain boundary: temporary root prepares the device for a known BootROM-based unlock path by restoring a compatible preloader.

Methodology

1. Establish the baseline

Before changing the device, I identified the hardware codename and recorded the Fire OS, build, bootloader, and kernel versions over ADB.

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

The resulting baseline was sheldonp / AFTSSS, Fire OS PS7716.5666N, incremental 0036005356164, Android 9, and kernel 4.4.162+. The serial number is deliberately omitted.

2. Obtain temporary root with GhostLock

I connected the Fire TV over USB with ADB debugging enabled and used GhostLock 1.1.0, the sheldon/sheldonp package published with the R0rt1z2 XDA guide. The device-specific launcher reboots the Fire TV to start from a fresh state, deploys the exploit, and retries when necessary.

Successful exploitation creates a temporary root environment. I verified the security context from an ADB shell rather than treating script completion alone as proof:

adb shell
su
id

The root context is ephemeral and is lost on reboot. That behavior is important: this stage is an enabling primitive for the downgrade, not the final persistence mechanism or the bootloader unlock itself.

The successful run showed uid=0, changed SELinux to permissive for the temporary environment, mounted the temporary su, and disabled the Fire OS OTA packages handled by the tool.

The full GhostLock exploit trace is retained as supporting evidence.

3. Downgrade the preloader

With temporary root available, I used the package's dedicated downgrade workflow instead of manually writing firmware partitions. This restored a preloader compatible with the existing Kamakiri path.

After the downgrade, the Fire TV intentionally stopped booting into Fire OS. In this specific workflow, that non-booting state is the expected handoff between the live-kernel stage and the USB BootROM stage. It must not be confused with proof that an arbitrary failed flash is recoverable.

[!CAUTION] Never erase Preloader. Do not improvise writes to LK, TEE, Preloader, boot, recovery, system, vendor, or other protected partitions. The upstream guides warn that damage to critical firmware can cause a permanent hard brick because a working recovery path may not remain available.

4. Run the Kamakiri BootROM chain

The Kamakiri workflow used for this device was supported and documented for Linux. I therefore booted an Ubuntu Live session and performed the full unlock workflow there, including the low-level USB BootROM stage, without installing Ubuntu on the host. I did not test this stage on Windows or macOS.

Using the sheldon/sheldonp Kamakiri package referenced by the unlock guide, the process was:

1. Prepare Python, PySerial, PyUSB, ADB, Fastboot, and the USB environment required by Kamakiri.
2. Start bootrom-step.sh and connect the powered-off Fire TV over USB.
3. Allow the BootROM stage to complete and transition the device into the modified fastboot environment.
4. Run fastboot-step.sh to finish the unlock workflow.
5. Reboot and verify that the expected unlocked boot path was available.

Kamakiri detected the unit as sheldonp, completed the RPMB downgrade, flashed the chain's required TZ/LK components, injected the microloader, and forced the device into its hacked fastboot mode.

The archive hashes and Ubuntu release are recorded above. Readers should use the linked upstream guides for version-specific instructions rather than assuming these high-level steps apply to another build.

5. Validate the result

I treated the following as separate milestones and captured evidence for each one:

6. Preserve Fire OS and adjust the post-unlock state

My goal was to retain stock Fire OS rather than install a custom ROM immediately. In TWRP I avoided wiping data or replacing the operating system, then rebooted into the existing Fire OS installation. TWRP and the unlocked boot path remained available while the stock user environment was preserved.

After returning to Fire OS, I kept OTA updates disabled so Amazon could not silently move the device to a build that changed the exploit or modified the recovered boot chain. I also disabled the Amazon system app-protection component commonly referred to in Fire TV community tooling as ARCUS. This changes Amazon's OS-level app-blocking behavior; it does not bypass Widevine, subscription checks, or license enforcement implemented inside individual applications.

Optional next steps

An unlocked bootloader and TWRP also make it possible to install compatible custom software. One community option for this device family is LineageOS 20 based on Android 13. Other compatible ROMs, recovery workflows, or persistent-root configurations may also be possible.

Those alternatives were not part of this reproduction. They should be treated as separate procedures with their own firmware, TZ, data-wipe, DRM, memory, and recovery considerations.

Observations

• A wired USB ADB connection is preferable because exploit retries can reboot the target and interrupt wireless ADB.
• Exploit reliability is target- and build-dependent. A retry or reboot is not evidence that a device is unsupported, but offsets and build compatibility must still be verified.
• The temporary-root stage and the Kamakiri stage solve different problems and should be documented independently.
• The expected post-downgrade non-booting state is only meaningful when the downgrade tool reports success and the exact supported workflow is being followed.
• A successful script exit is weaker evidence than captured device state, root identity, and fastboot/recovery verification.
• Unlocking the bootloader did not require replacing Fire OS; keeping stock Fire OS was a deliberate post-unlock choice.
• Disabling ARCUS affects Amazon's app-blocking layer, while application DRM and content licenses remain separate concerns.

Security impact

On a vulnerable and supported Fire OS build, code already running locally on the device can exploit the kernel flaw to obtain a temporary root context. In this lab, that access expanded the attack surface beyond the running operating system: it enabled a firmware downgrade that reintroduced a boot-chain condition usable by an older BootROM exploit.

This chain illustrates why device security depends on more than patching a single layer. A kernel privilege escalation can become a bridge to lower-level persistence or boot-chain compromise when privileged software can modify security-critical firmware state.

Repository structure

.
├── 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

This repository does not redistribute the third-party ZIP archives. Obtain them from the original XDA guides, review their applicable terms, and compare their hashes with the values recorded above.

Credits

• NebuSec / CyberMeowfia — discovery and original IonStack/GhostLock research and exploit implementation for CVE-2026-43499.
• R0rt1z2 — Fire OS adaptation, the 4.4 GhostLock branch, and the sheldon/sheldonp temporary-root and downgrade guide.
• IonStackQuest3 — first public GhostLock port for Linux 5.10 kernels, credited by the downstream Fire OS project.
• Amonet/Kamakiri contributors, including xyz, k4y0z, Rortiz2, t0x1cSH, and testers credited in the original unlock thread — BootROM, fastboot, recovery, and device-specific unlock work.

My contribution is the independent reproduction, device-specific execution record, analysis of how the stages connect, and the original evidence published in this repository.

References

The maintained source ledger is in references/README.md. Primary sources include:

• CVE-2026-43499 record
• NebuSec: GhostLock vulnerability entry
• NebuSec: IonStack Part III — Android exploitation
• CyberMeowfia: IonStack/CVE-2026-43499 source
• R0rt1z2/GhostLock, 4.4 branch
• XDA: temporary root and preloader downgrade for sheldon/sheldonp
• Amonet/Kamakiri source
• XDA: bootloader unlock, TWRP, and unbrick guide for sheldon/sheldonp
• Linux kernel fix for remove_waiter()

Responsible-use notice

This material is provided for educational use and authorized security research on hardware you own or are explicitly permitted to test. It comes with no warranty. You are responsible for legal compliance, data loss, service disruption, and hardware damage resulting from your actions.

License

Original text and images authored for this repository are licensed under the Creative Commons Attribution 4.0 International License.

Third-party tools, exploit code, firmware, quotations, screenshots, trademarks, and referenced materials remain subject to their respective authorship and licenses. Inclusion of a link or credit does not relicense that material under CC BY 4.0.