Description

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

Executive Summary

Technical Details

Mitigations

References

Additional Metadata

{
  "score": "7.6",
  "pubDate": "2026-08-19T17:18:21.440Z",
  "pubdate": "2026-08-19T17:18:21.440Z",
  "executiveSummary": "The Secure BootROM of the RK3588s SoC is vulnerable to a time-of-check to time-of-use (TOCTOU) race condition when booting from external storage media, including SPI NOR, SPI NAND, eMMC, or SD cards.\nThis flaw allows an attacker with physical access and low-cost hardware emulation tools to bypass signature and hash validation mechanisms during the boot sequence.\nSuccessful exploitation leads to arbitrary code execution with the highest available privileges at Exception Level 3 (EL3), completely compromising the hardware root of trust.\nThe vulnerability specifically affects the RK3588s SoC BootROM (secure) version 350B20210512V100 and potentially other related versions.\nRisk implications are severe, as an adversary can subvert the secure boot chain to execute unauthorized firmware.\nExploitation requires physical access to the device and the ability to manipulate data on external storage interfaces on-the-fly using hardware emulators or multiplexing circuits.",
  "technicalDetails": "The root cause of the vulnerability lies in a flawed validation sequence within the Secure BootROM when loading the next-stage loader from external media.\nThe BootROM reads the header of the next-stage loader twice. The header contains cryptographic hashes of the executable modules and is signed with a private key, with the corresponding public key verified against a SHA256 digest permanently blown into the OTP memory.\nDuring the first read operation, the BootROM reads only a partial section of the header containing the hashes of the executable modules.\nDuring the second read operation, the BootROM reads the complete header, including the cryptographic signature.\nAlthough the cryptographic signature is verified against the fully read data during the second read, the authenticity and integrity of the actual executable modules are checked against the partial data retrieved during the first read.\nAn attacker with physical access to the device can exploit this architectural discrepancy using a low-cost SD card, SPI NOR/NAND, or eMMC emulator.\nAlternatively, an ultra-low-cost circuit comprising two memory chips loaded with identical data except for differing headers (one original and one modified) coupled with a multiplexer can be utilized to execute the attack.\nThe attack flow proceeds as follows: first, the malicious hardware presents legitimate header data and hashes during the initial partial read, allowing the BootROM to store the attacker-controlled hashes for subsequent module validation.\nSecond, the hardware switches or modifies the data on-the-fly before the second read occurs, presenting a valid signed header to pass the signature check.\nBecause the BootROM validates the executable modules against the hashes cached from the first read rather than the cryptographically verified structures from the second read, arbitrary malicious modules are accepted.\nThis bypasses the secure boot chain entirely, resulting in arbitrary code execution at Exception Level 3 (EL3)."
}