CVE-2024-13942: RK3588s SoC Secure BootROM RCE Flaw

CVE-2024-13942 Overview

CVE-2024-13942 is a time-of-check to time-of-use (TOCTOU) vulnerability [CWE-367] in the Secure BootROM of the Rockchip RK3588s System-on-Chip (SoC). The flaw affects the boot flow when the SoC loads the next-stage bootloader from external media, including SPI NOR/NAND flash, eMMC, and SD cards. The BootROM reads the loader header twice, verifying the signature against the fully read data while checking executable module authenticity against the earlier partial read. An attacker with physical access can swap the loader contents between the two reads and gain arbitrary code execution at EL3, the highest ARM exception level. The issue affects RK3588s BootROM version 350B20210512V100 and possibly other revisions.

Critical Impact
Successful exploitation grants arbitrary code execution at EL3, breaking the chain of trust established by Secure Boot on any device built around the RK3588s SoC.

Affected Products

Rockchip RK3588s SoC Secure BootROM version 350B20210512V100
Devices booting from external SPI NOR, SPI NAND, eMMC, or SD media
Other RK3588s BootROM revisions may also be affected

Discovery Timeline

2026-08-19 - CVE-2024-13942 published to NVD
2026-08-19 - Last updated in NVD database

Technical Details for CVE-2024-13942

Vulnerability Analysis

The RK3588s Secure BootROM implements a signed-boot scheme in which the next-stage loader header carries SHA-256 hashes of the executable modules and is itself signed with a private key. The public key is validated against a digest burned into the SoC's one-time programmable (OTP) memory. This chain establishes the integrity of every stage that runs before the operating system.

The BootROM reads the loader header from external media twice. The first read is partial and pulls in only the module hashes. The second read is complete and includes the header signature. Signature verification runs over the second, fully-read header, but module authentication uses the hash values captured during the first read. An attacker who can change what the SoC sees between the two reads breaks the binding between the signed hashes and the hashes actually used to verify the payload.

Root Cause

The root cause is a classic TOCTOU pattern [CWE-367]: the BootROM checks one copy of a data structure and then relies on a different, earlier copy for a security-critical decision. Because the storage medium is untrusted and external to the SoC, the two reads are not guaranteed to return the same bytes. The BootROM does not cache or hash the initially read module digests inside the signature-verified structure.

Attack Vector

Exploitation requires physical access to the target device but no privileges or user interaction. A low-cost SD card, SPI NOR/NAND, or eMMC emulator can serve two different images depending on read offset or read sequence. Even a static circuit built from two memory chips and a multiplexer is sufficient: one chip holds the original signed loader and the other holds an attacker-modified loader that shares a valid header but points to malicious modules. The multiplexer switches between them between the first and second BootROM read. Because the resulting code runs at EL3, it precedes and can compromise the trusted execution environment, hypervisor, and operating system.

See the GitHub Security Advisory KLSA-00230 for the detailed technical write-up.

Detection Methods for CVE-2024-13942

Indicators of Compromise

Unexpected hardware attached to boot-media pins, including inline SD, eMMC, or SPI interposers between the storage device and the SoC
Physical tampering evidence on device enclosures, such as broken seals or added flying leads near the boot flash
Boot logs showing unexpected firmware versions, unsigned components loaded at EL3, or discrepancies between advertised and running loader hashes

Detection Strategies

Compare on-device measurements of the loader against a known-good digest computed from the signed image and flag mismatches
Enroll RK3588s devices in a remote attestation flow so that post-boot software can prove the identity of the loader that actually executed
Perform periodic tamper inspections and photograph internals of fielded devices to detect added emulators or multiplexers

Monitoring Recommendations

Track downstream firmware behavior for anomalies such as disabled Secure Boot policies, unexpected kernel modules, or missing measured-boot events
Instrument fleet telemetry to alert on devices whose first-boot fingerprint changes after deployment
Correlate physical-access events with subsequent boot-time integrity failures on the same device

How to Mitigate CVE-2024-13942

Immediate Actions Required

Apply mitigations per the Rockchip PSIRT instructions for RK3588s
Discontinue use of RK3588s-based devices in threat models where an attacker may obtain physical access, if vendor mitigations are unavailable
Inventory all RK3588s devices and identify those booting from external SPI NOR/NAND, eMMC, or SD media, which are the exposed configurations

Patch Information

The vulnerability resides in immutable BootROM code and cannot be corrected with a software patch. Refer to the Rockchip RK3588s product page and the Rockchip PSIRT advisory for vendor guidance on hardware-level and next-stage-loader mitigations. Long-term remediation requires a silicon revision that eliminates the double-read pattern.

Workarounds

Design devices so that the boot chain runs from internal, non-removable storage that is not accessible on external pads or connectors
Add physical tamper detection and enclosure hardening to raise the cost of installing a media emulator
Enforce end-to-end attestation from a later boot stage so that a compromised EL3 payload cannot silently pass fleet health checks

bash

# Configuration example
# No software configuration can remediate a BootROM TOCTOU flaw.
# Follow vendor guidance from Rockchip PSIRT and treat physical
# access to RK3588s boot media as a high-severity risk.