Skip to main content
CVE Vulnerability Database
Vulnerability Database/CVE-2025-46733

CVE-2025-46733: OP-TEE Trusted Execution Environment DoS Flaw

CVE-2025-46733 is a denial of service vulnerability in OP-TEE Trusted Execution Environment that allows attackers to trigger panics in TAs using Secure Storage API, potentially resetting PCR values and exposing sensitive data. This article covers technical details, affected versions, impact on fTPM TA, and available mitigation strategies.

Published:

CVE-2025-46733 Overview

CVE-2025-46733 affects OP-TEE, a Trusted Execution Environment (TEE) that runs alongside a non-secure Linux kernel on Arm Cortex-A cores using TrustZone technology. In version 4.5.0, a local attacker with the ability to replace the tee-supplicant binary in the Rich Execution Environment (REE) userspace can trigger a panic in a Trusted Application (TA) that uses the libutee Secure Storage API. The most impactful target is the optee_ftpm TA, where the panic enables Platform Configuration Register (PCR) reset, allowing falsified boot measurements and access to sealed data.

Critical Impact

A local attacker able to replace tee-supplicant can panic the fTPM TA, reset non-resettable PCRs, and re-extend them to falsify boot measurements or unseal protected data.

Affected Products

  • OP-TEE OS version 4.5.0
  • Trusted Applications using the libutee Secure Storage API
  • The optee_ftpm Trusted Application (firmware TPM)

Discovery Timeline

  • 2025-07-04 - CVE-2025-46733 published to NVD
  • 2026-06-17 - Last updated in NVD database

Technical Details for CVE-2025-46733

Vulnerability Analysis

OP-TEE bridges secure and non-secure worlds through tee-supplicant, a userspace daemon that services storage requests from Trusted Applications. The libutee Secure Storage API mandates that TAs panic when a system call returns an unexpected return code, per the TEE Internal Core API specification. OP-TEE passes return codes from tee-supplicant through the Linux tee-driver and OP-TEE kernel back to libutee without sanitization. This weakness maps to [CWE-755: Improper Handling of Exceptional Conditions].

A malicious tee-supplicant responds to storage requests with unexpected codes, causing the requesting TA to panic. TAs built with TA_FLAG_SINGLE_INSTANCE (gpd.ta.singleInstance) and TA_FLAG_INSTANCE_KEEP_ALIVE (gpd.ta.keepAlive) rely on memory preserved across sessions. Panicking and reloading the TA clears that memory. For optee_ftpm, that memory holds PCR values that must remain non-resettable to preserve the chain of trust.

Root Cause

Secure Storage return codes originate in untrusted REE userspace and are propagated to libutee without validation. libutee treats any unexpected return code as a fatal condition and panics, giving the untrusted supplicant direct control over TA lifecycle.

Attack Vector

An attacker with local access to REE userspace stops the legitimate tee-supplicant and starts a malicious replacement. Root privileges make this trivial, and permissive configurations may allow lower-privileged users to do the same. The malicious supplicant returns crafted error codes on storage requests, triggering a panic. After restart, the TA's keepAlive memory is zeroed. Against the fTPM TA, an attacker resets PCRs and extends them with attacker-chosen values, forging boot measurements and unsealing data bound to prior PCR states.

c
// Patch excerpt: core/kernel/tee_ta_manager.c
// Introduces tracking for a crashed keep-alive TA instance.
	struct tee_ta_session *sess = NULL;
	struct tee_ta_ctx *ctx = NULL;
	struct ts_ctx *ts_ctx = NULL;
+	bool keep_crashed = false;
	bool keep_alive = false;

	DMSG("csess 0x%" PRIxVA " id %u",
c
// Patch excerpt: lib/libutee/include/user_ta_header.h
// New TA flag prevents restart of a crashed keep-alive TA.
					BIT32(11)
 #define TA_FLAG_DEVICE_ENUM_TEE_STORAGE_PRIVATE	\
 					BIT32(12) /* with TEE_STORAGE_PRIVATE */
+/*
+ * Don't restart a TA with TA_FLAG_INSTANCE_KEEP_ALIVE set if it has
+ * crashed.
+ */
+#define TA_FLAG_INSTANCE_KEEP_CRASHED	BIT32(13)

-#define TA_FLAGS_MASK			GENMASK_32(12, 0)
+#define TA_FLAGS_MASK			GENMASK_32(13, 0)

Source: OP-TEE fix commit 941a58d

Detection Methods for CVE-2025-46733

Indicators of Compromise

  • Unexpected termination or restart of the tee-supplicant daemon on affected devices.
  • New or modified tee-supplicant binary outside the vendor-provided installation path.
  • TA panic entries in the OP-TEE kernel log referencing Secure Storage API functions in libutee.
  • Unexpected PCR reset events or boot-attestation mismatches reported by the fTPM TA.

Detection Strategies

  • Monitor process lineage and integrity of tee-supplicant; alert when a non-authorized binary binds to the TEE device.
  • Alert on repeated TA panics tied to Secure Storage calls, which indicate a malicious supplicant responding with unexpected codes.
  • Correlate remote attestation failures with local process changes to tee-supplicant.

Monitoring Recommendations

  • Enable file integrity monitoring on /usr/sbin/tee-supplicant and equivalent paths.
  • Forward OP-TEE and Linux tee-driver logs to a centralized platform for correlation with authentication and process telemetry.
  • Track fTPM PCR values against a known baseline and alert on unexpected resets or extensions.

How to Mitigate CVE-2025-46733

Immediate Actions Required

  • Update OP-TEE OS to a build containing commit 941a58d78c99c4754fbd4ec3079ec9e1d596af8f or later.
  • Restrict access to the OP-TEE device node so only privileged, trusted processes can invoke TEE operations.
  • Restrict the ability to stop, replace, or execute tee-supplicant to a minimal set of accounts.
  • Rebuild affected TAs, including optee_ftpm, to adopt the new TA_FLAG_INSTANCE_KEEP_CRASHED behavior.

Patch Information

The fix is available in OP-TEE commit 941a58d78c99c4754fbd4ec3079ec9e1d596af8f. The patch adds a TA_FLAG_INSTANCE_KEEP_CRASHED flag so that a crashed TA_FLAG_INSTANCE_KEEP_ALIVE TA is not silently restarted, preserving the integrity of session-persistent state such as fTPM PCRs. See the GHSA-f35r-hm2m-p6c3 advisory for vendor guidance.

Workarounds

  • Harden filesystem permissions so unprivileged users cannot stop tee-supplicant or execute a replacement binary.
  • Enforce mandatory access control (SELinux, AppArmor) policies that restrict which binaries may open /dev/tee* and /dev/teepriv*.
  • Use remote attestation to detect PCR resets and refuse to release sealed secrets to devices whose measurements changed unexpectedly.
bash
# Restrict tee-supplicant and TEE device access to a dedicated service account
chown root:tee /usr/sbin/tee-supplicant
chmod 0750 /usr/sbin/tee-supplicant
chown root:tee /dev/tee0 /dev/teepriv0
chmod 0660 /dev/tee0 /dev/teepriv0

Disclaimer: This content was generated using AI. While we strive for accuracy, please verify critical information with official sources.

Default Legacy - Prefooter | Experience the World’s Most Advanced Cybersecurity Platform

Experience the Most Advanced Cybersecurity Platform

See how the world’s most intelligent, autonomous cybersecurity platform can protect your organization today and into the future.