CVE-2026-41516: OP-TEE Hisilicon HPRE RSA Padding Oracle Vulnerability

Technical summary

The Hisilicon HPRE crypto driver in OP-TEE implements RSA PKCS#1 v1.5 decryption with a timing-dependent vulnerability in label hash verification. The implementation uses non-constant-time memcmp() for cryptographic comparison and exposes multiple distinguishable error paths, creating a padding oracle attack surface consistent with Bleichenbacher's original 1998 attack methodology. An attacker capable of submitting crafted ciphertexts and measuring response timing can gradually recover plaintext through statistical analysis of error conditions. The vulnerability chain involves both the non-constant-time comparison and the leakage of distinct error states, making mitigation require both timing equalization and error path consolidation.

Business impact

For deployments relying on OP-TEE with Hisilicon HPRE acceleration for RSA operations—primarily in certain embedded and IoT devices—this creates a confidentiality risk. An attacker with local system access could potentially decrypt sensitive RSA-protected data such as encryption keys, credentials, or other cryptographic material processed through the TEE. The practical impact depends on the deployment model: if RSA decryption is used primarily for key unwrapping or protocol negotiation where high-value secrets are at stake, the risk is elevated; if used for lower-risk operations, exposure is more limited. The low CVSS score reflects the required local access and architectural constraints, but the nature of the vulnerability (plaintext recovery) warrants timely patching in any production use case involving key material.

Affected systems

OP-TEE versions 4.5.0 through 4.10.x are affected. The vulnerability is specific to systems using the Hisilicon HPRE hardware crypto accelerator and configured with RSA PKCS#1 v1.5 decryption enabled. Systems not using Hisilicon acceleration or not performing RSA decryption through the affected code path are unaffected. Arm Cortex-A processors with TrustZone technology are the target architecture; this primarily impacts embedded systems, edge devices, and specialized IoT deployments rather than general-purpose computing.

Exploitability

Exploitation requires local code execution on the target device—the attacker must be able to run code on the non-secure Linux kernel or have direct access to cryptographic operations. No network-based exploitation is possible. The attacker must then perform cryptanalysis by submitting many crafted RSA ciphertexts and measuring or observing timing differences in the TEE's response. This is a theoretical vulnerability with moderate practical difficulty: it requires both local access and sustained interaction with the cryptographic implementation, but the attack methodology is well-established in the literature. No public exploit code or in-the-wild attacks have been reported, and the vulnerability is not on the CISA Known Exploited Vulnerabilities list.

Remediation

Upgrade OP-TEE to version 4.11.0 or later, which includes constant-time fixes for RSA PKCS#1 v1.5 label hash verification and error path consolidation. For organizations unable to upgrade immediately, the vendor provides a workaround: disable the Hisilicon HPRE RSA driver by setting CFG_HISILICON_ACC_V3=n during OP-TEE build configuration. This workaround trades performance for security by falling back to software RSA implementation. Verify your build configuration and test thoroughly in staging before applying changes to production TEE deployments.

Patch guidance

OP-TEE version 4.11.0 contains the patch. Obtain the update from the official Trusted Firmware OP-TEE repository and verify checksums and signatures. As with all TEE updates, perform testing in a staging environment that mirrors your production TEE configuration, including hardware accelerator settings and cryptographic workload patterns. TEE firmware updates may require coordination with device vendors if they have customized or repackaged OP-TEE for specific hardware. Contact your hardware vendor to confirm availability of patched firmware for your specific Hisilicon platform variant.

Detection guidance

Monitor OP-TEE logs for RSA PKCS#1 v1.5 decryption errors or unusual error patterns. Detection of active exploitation is challenging without instrumentation; the attack generates legitimate-looking API calls with only subtle timing side-channels. Consider enabling TEE debug logging during investigation phases to capture error paths. If you maintain a cryptographic audit trail, look for patterns of repeated failed RSA decryption operations with different inputs—a hallmark of padding oracle probing. Review your deployment to confirm which cryptographic operations actually use RSA PKCS#1 v1.5 decryption; many modern systems have migrated to OAEP padding, which is not vulnerable to this class of attack.

Why prioritize this

Although the CVSS score is low due to local-access requirements, the nature of the vulnerability warrants prompt attention: RSA plaintext recovery is a high-impact breach of confidentiality, and the attack is based on well-understood cryptographic weaknesses. Prioritize based on: (1) whether your systems use Hisilicon HPRE acceleration, (2) whether RSA PKCS#1 v1.5 is actually in use rather than OAEP, and (3) whether the plaintext being decrypted includes high-value secrets. In most embedded deployments, local access is a significant barrier; however, if your threat model includes local attackers or supply-chain compromises, this rises to medium priority.

Risk score, explained

The CVSS 3.1 score of 2.5 (LOW) reflects: Attack Vector = Local (not remotely exploitable), Access Complexity = High (requires cryptanalysis and timing measurement), Privileges Required = Low (authenticated local user), User Interaction = None, and Impact = Low confidentiality impact only (no integrity or availability loss). However, the score underweights the cryptographic severity—plaintext recovery of RSA-protected data is inherently high-impact. The CVSS model penalizes local-only attacks and the effort required for cryptanalysis. For security decision-making, consider the actual value of the protected data independently of the CVSS number.

Frequently asked questions