CVE-2025-46733
Awaiting Analysis Awaiting Analysis - Queue
BaseFortify

Publication date: 2025-07-04

Last updated on: 2025-07-08

Assigner: GitHub, Inc.

Description
OP-TEE is a Trusted Execution Environment (TEE) designed as companion to a non-secure Linux kernel running on Arm; Cortex-A cores using the TrustZone technology. In version 4.5.0, using a specially crafted tee-supplicant binary running in REE userspace, an attacker can trigger a panic in a TA that uses the libutee Secure Storage API. Many functions in libutee, specifically those which make up the Secure Storage API, will panic if a system call returns an unexpected return code. This behavior is mandated by the TEE Internal Core API specification. However, in OP-TEE’s implementation, return codes of secure storage operations are passed through unsanitized from the REE tee-supplicant, through the Linux kernel tee-driver, through the OP-TEE kernel, back to libutee. Thus, an attacker with access to REE userspace, and the ability to stop tee-supplicant and replace it with their own process (generally trivial for a root user, and depending on the way permissions are set up, potentially available even to less privileged users) can run a malicious tee-supplicant process that responds to storage requests with unexpected response codes, triggering a panic in the requesting TA. This is particularly dangerous for TAs built with `TA_FLAG_SINGLE_INSTANCE` (corresponding to `gpd.ta.singleInstance` and `TA_FLAG_INSTANCE_KEEP_ALIVE` (corresponding to `gpd.ta.keepAlive`). The behavior of these TAs may depend on memory that is preserved between sessions, and the ability of an attacker to panic the TA and reload it with a clean memory space can compromise the behavior of those TAs. A critical example of this is the optee_ftpm TA. It uses the kept alive memory to hold PCR values, which crucially must be non-resettable. An attacker who can trigger a panic in the fTPM TA can reset the PCRs, and then extend them PCRs with whatever they choose, falsifying boot measurements, accessing sealed data, and potentially more. The impact of this issue depends significantly on the behavior of affected TAs. For some, it could manifest as a denial of service, while for others, like the fTPM TA, it can result in the disclosure of sensitive data. Anyone running the fTPM TA is affected, but similar attacks may be possible on other TAs that leverage the Secure Storage API. A fix is available in commit 941a58d78c99c4754fbd4ec3079ec9e1d596af8f.
CVSS Scores
EPSS Scores
Probability:
Percentile:
Meta Information
Published
2025-07-04
Last Modified
2025-07-08
Generated
2026-05-07
AI Q&A
2025-07-04
EPSS Evaluated
2026-05-05
NVD
CVE-2025-46733
Affected Vendors & Products
Currently, no data is known.
Helpful Resources
Exploitability
CWE
CWE Icon
KEV
KEV Icon
CWE ID Description
CWE-755 The product does not handle or incorrectly handles an exceptional condition.
Attack-Flow Graph
AI Powered Q&A
Can you explain this vulnerability to me?

CVE-2025-46733 is a vulnerability in OP-TEE's Trusted Execution Environment where an attacker with access to the non-secure userspace (REE) can replace the legitimate tee-supplicant process with a malicious one. This malicious tee-supplicant returns unexpected error codes to the Secure Storage API calls in the Trusted Applications (TAs). Because the libutee library panics when it receives unexpected return codes, this causes the TA to panic and restart. This is especially problematic for TAs that keep state between sessions, like the firmware TPM (fTPM) TA, where panicking resets critical memory, allowing an attacker to falsify boot measurements and potentially access sealed data. [2]


How can this vulnerability impact me? :

This vulnerability can lead to denial of service by causing Trusted Applications to panic and restart unexpectedly. More critically, for TAs like the fTPM TA that maintain persistent state (e.g., PCR values), an attacker can reset these values by triggering a panic, then manipulate them to falsify system integrity measurements. This can result in unauthorized access to sealed data, falsified TPM measurements, and compromise of system security guarantees. [2]


How can this vulnerability be detected on my network or system? Can you suggest some commands?

This vulnerability can be detected by monitoring for panics or crashes in Trusted Applications (TAs) that use the Secure Storage API, especially those with TA_FLAG_SINGLE_INSTANCE and TA_FLAG_INSTANCE_KEEP_ALIVE flags such as the optee_ftpm TA. Detection involves checking if the tee-supplicant process has been stopped or replaced by a malicious version in the Rich Execution Environment (REE) userspace. One can look for unusual tee-supplicant behavior or logs indicating unexpected return codes causing TA panics. While no specific commands are provided, monitoring the tee-supplicant process status and TA panic logs is recommended. For example, commands like `ps aux | grep tee-supplicant` to verify the running tee-supplicant binary, and checking kernel or OP-TEE logs for TA panics could help detect exploitation attempts. [2]


What immediate steps should I take to mitigate this vulnerability?

Immediate mitigation steps include preventing unauthorized users from stopping or replacing the tee-supplicant process in the REE userspace, by tightening permissions and access controls. Additionally, updating OP-TEE to include the fix introduced in commit 941a58d78c99c4754fbd4ec3079ec9e1d596af8f is recommended. This fix adds the `optee.ta.instanceKeepCrashed` property and the `TA_FLAG_INSTANCE_KEEP_CRASHED` flag, which prevent TAs from being automatically restarted after a crash, preserving their state and preventing the attack vector. Until the fix is applied, monitoring for suspicious tee-supplicant replacements and TA panics is critical. [1, 2]


Ask Our AI Assistant
Need more information? Ask your question to get an AI reply (Powered by our expertise)
0/70
EPSS Chart