ZXIC/Sanechips ZX297520V3 BootROM Arbitrary Memory Write via USB Download Mode (CVE-2026-40003)

Metadata

Affected Target

Summary

The ZX297520V3 BootROM falls back to a USB download mode when it cannot load or verify a valid image from flash, entering a handshake loop that accepts a stage-1 image over USB for device recovery. The BootROM’s image-load command does not validate the destination address it is told to write to, allowing an attacker with physical USB access to write arbitrary data to arbitrary memory, including onto the boot stack. By further abusing the lack of any one-time-download restriction, the PoC sends a first payload to a chosen address, then overwrites the saved return address on the stack so that when image verification fails and verify_and_jump returns into usbdl_init, execution redirects into the attacker-controlled payload instead of normal error handling — achieving code execution on the BootROM before any anti-rollback/signature checks apply.

Vulnerability Details

Root Cause

Missing bounds/destination validation in the BootROM’s USB download command handler (opcode 0x7A): the handler accepts an arbitrary start_addr/size pair from the host and writes host-supplied bytes there without restricting the range to a safe scratch buffer, combined with no one-time-use restriction on the download command itself.

Attack Vector

1. Trigger USB download mode on the target device (via a hardware test point or by corrupting the flash boot image).
2. Send a first payload image to a chosen memory address using the USB download protocol.
3. Compute the stack offset of the saved link register based on the entry/usbdl_init function prologues (8 words in this BootROM build).
4. Send a second “image” whose content overwrites the saved LR slot on the stack with the address of the attacker’s payload.
5. Send the jump/verify command and deliberately let image-magic verification fail.
6. verify_and_jump returns into usbdl_init, which executes its POP {R4, PC} epilogue — popping the attacker-controlled address into PC and transferring control to the payload.

Impact

Arbitrary code execution in BootROM context on the ZX297520V3 SoC prior to any signature verification, enabling full compromise/unlock of the baseband/modem device via nothing more than physical USB access — with no software fix possible for chips already in the field (only newer silicon revisions are fixed).

Environment / Lab Setup

Target:   Device with a ZX297520V3 SoC, USB download mode reachable via test point or corrupted flash
Attacker: Rust toolchain (rustup, thumbv6m-none-eabi target), llvm-objcopy, gcc, root/sudo for raw USB access

Proof of Concept

PoC Script

See loader/src/main.rs (host-side USB loader/exploit) and payload/src/main.rs (Cortex-M0 payload run on the BootROM) in this folder.

1
2

cd payload && ./build.sh && cd ..
sudo -E cargo r -p loader -- target/thumbv6m-none-eabi/release/payload

After building the bare-metal payload, the loader tool is run with root privileges to access the USB device directly; with the target device held in USB download mode, the loader performs the handshake, uploads the payload to the chosen address, corrupts the saved stack return address to redirect execution into it, and triggers the verification-failure code path so the BootROM jumps into the payload — observable via UART output on the device.

Detection & Indicators of Compromise

Signs of compromise:

• Device entering USB download mode outside of an authorized service/recovery flow
• Unexpected payload execution evidenced by UART output diverging from the normal boot sequence
• Repeated USB image-download command sequences (opcode 0x7A) observed on the USB bus without a corresponding legitimate firmware-recovery session

Remediation

References

• Source repository

Notes

Mirrored from https://github.com/rva3/CVE-2026-40003 on 2026-07-05.