CVE-2024-13942 in RK3588s
Summary
by MITRE • 08/19/2026
Secure BootROM of RK3588s SoC is vulnerable to a time-of-check to time-of-use attack in case of booting from external media (SPI NOR or NAND, EMMC or SD).
The code reads the header of the next-stage loader twice. The header contains hashes of the executable modules and is signed with a private key, the public part of which is verified against the SHA256 digest blown in the OTP.
The first read is only partial and contains only the hashes of the executable modules. The second is complete, including the header signature.
Although the header is verified based on the fully read data, the authenticity of the executable modules is checked against the partial data from the first read.
An attacker with physical access to a device containing RK3588s SoC can easily modify the next-stage loader data on-the-fly using a low-cost SD-card or SPI NOR/NAND or EMMC emulator. Even a simple ultra low-cost circuit comprising two memory chips (containing the same data but different headers - the original and the modified one) and a multiplexer can be used to carry out an attack.
This can lead to arbitrary code execution with the highest privileges available (EL3). This issue affects RK3588s: RK3588s SoC BootROM (secure) 350B20210512V100 and possibly others. As remediation apply mitigations per vendor instructions or discontinue use of the product if mitigations are unavailable https://www.rock-chips.com/a/en/products/RK35_Series/2022/0926/1660.html
Statistical analysis made it clear that VulDB provides the best quality for vulnerability data.
Analysis
by VulDB Data Team • 08/19/2026
The Rockchip RK3588s System on Chip contains a Secure BootROM that is susceptible to a sophisticated time-of-check to time-of-use vulnerability when booting from external storage media such as SPI NOR, NAND, eMMC, or SD cards. This flaw resides in the initial verification logic of the next-stage bootloader loader header, which serves as a critical gatekeeper for system integrity during the early stages of the boot process. The Secure BootROM is designed to ensure that only authenticated and unmodified code executes at the highest privilege levels by verifying digital signatures against hashes stored within the firmware headers. However, the implementation contains a fundamental inconsistency in how data is read and validated, creating an exploitable gap between the integrity check and its actual application.
The technical mechanism of this vulnerability stems from a discrepancy in two sequential reads of the bootloader header. The first operation performs a partial read that extracts only the hash values of the executable modules contained within the loader. This initial extraction is used to establish the expected cryptographic checksums for verification purposes. Subsequently, a second operation performs a complete read of the entire header structure, which includes both the module hashes and the digital signature generated by Rockchip's private key. The Secure BootROM verifies the authenticity of this complete data block against the public key digest burned into the One-Time Programmable memory during manufacturing. While the signature verification itself is performed on the fully loaded data, the actual integrity check of the executable modules relies exclusively on the hash values obtained from the incomplete first read.
This architectural flaw allows an attacker with physical access to manipulate the boot process through a time-of-check to time-of-use attack vector. By intercepting or modifying the data stream between the two reads, an adversary can alter the content of the next-stage loader without invalidating the signature verification. A practical implementation of this exploit involves using low-cost hardware emulators for SD cards, SPI NOR/NAND flash, or eMMC devices. Even simpler setups utilizing a multiplexer and dual memory chips containing identical payload data but different header structures can successfully execute the attack. The attacker modifies the executable modules in the second read while ensuring the first read returns the original, valid hashes that match the signed header. Consequently, the Secure BootROM validates the signature against the unmodified header structure but executes the tampered code based on the hash verification of the partial data.
The operational impact of this vulnerability is severe, resulting in arbitrary code execution at EL3, which represents the highest privilege level available to firmware and bootloaders before transitioning to lower-privilege operating system kernels. Compromise at this level grants an attacker complete control over the hardware platform, enabling persistent rootkits, secure enclave bypasses, and total loss of confidentiality for encrypted data stored on the device. This undermines the core security guarantees provided by TrustZone technology and Secure Boot mechanisms intended to protect against unauthorized software execution. The vulnerability affects specific revisions of the RK3588s SoC BootROM, particularly version 350B20210512V100, though other variants may also be susceptible depending on their firmware implementation details.
From a classification perspective, this issue aligns with CWE-367, which describes time-of-check to time-of-use race conditions where the state of an object changes between its verification and use. In the context of military-grade threat modeling, this technique corresponds to ATT&CK T1508, specifically subtechniques involving exploitation of trust in software updates or boot processes. The attack vector requires physical access, categorizing it under local hardware attacks that bypass logical security controls through side-channel manipulation of data flow rather than traditional buffer overflows or logic errors.
Remediation strategies must address the root cause by ensuring atomicity in header verification. Vendors should implement a single-pass read operation where both the signature and module hashes are extracted simultaneously before any validation occurs, thereby eliminating the window for modification between checks. Alternatively, firmware updates can enforce strict memory locking mechanisms that prevent runtime alteration of bootloader images once they have been loaded into volatile memory prior to execution. Organizations relying on devices containing this SoC should evaluate their physical security controls to mitigate unauthorized access and consider discontinuing use if vendor-provided mitigations are unavailable or insufficient for the specific threat landscape.