CVE-2025-46733

Executive Summary

CVE-2025-46733 is a high-severity vulnerability in OP-TEE (Open Portable Trusted Execution Environment), version 4.5.0. The flaw resides in the libutee Secure Storage API, where return codes from the Rich Execution Environment (REE) tee-supplicant are passed unsanitized through the Linux kernel tee-driver and OP-TEE kernel back to the Trusted Application (TA). An attacker with REE userspace access can replace the legitimate tee-supplicant with a malicious one, causing a TA to panic by sending unexpected response codes. This is especially critical for TAs using TA_FLAG_SINGLE_INSTANCE and TA_FLAG_INSTANCE_KEEP_ALIVE, such as the optee_ftpm TA, where a panic resets PCR values, enabling falsification of boot measurements and access to sealed data. The vulnerability is unpatched in the wild, with a fix available in commit 941a58d78c99c4754fbd4ec3079ec9e1d596af8f.

Supply Chain & Package Security

This vulnerability is not in a package manager (NPM, PyPI, Go, Ruby) but in the OP-TEE source code. The supply chain risk is low unless downstream vendors distribute unpatched OP-TEE builds.

CVSS Breakdown & Threat Level

• CVSS Score: 7.9 (High)
• Vector: CVSS:3.1/AV:L/AC:L/PR:H/UI:N/S:C/C:H/I:H/A:H
• Attack Vector: Local (AV:L) – requires REE userspace access.
• Attack Complexity: Low (AC:L) – trivial to replace tee-supplicant.
• Privileges Required: High (PR:H) – typically root, but may be lower depending on permissions.
• User Interaction: None (UI:N) – no user action needed.
• Scope: Changed (S:C) – impacts TEE (Trusted Execution Environment) from REE.
• Confidentiality: High (C:H) – potential disclosure of sealed data.
• Integrity: High (I:H) – PCR values can be falsified.
• Availability: High (A:H) – TA panic leads to denial of service.

Threat Level: Critical for environments using fTPM or other keep-alive TAs. The EPSS score of 0.0% suggests low exploitation probability currently, but the impact is severe.

Deep Dive & Mechanics

OP-TEE is a TEE for Arm Cortex-A cores using TrustZone. The libutee Secure Storage API is used by TAs to store and retrieve data securely. The API relies on the REE tee-supplicant to handle storage operations. In a normal flow:

1. TA calls a Secure Storage function (e.g., TEE_ReadObjectData).
2. libutee sends a system call to OP-TEE kernel.
3. OP-TEE kernel forwards the request to REE via the tee-driver.
4. tee-supplicant processes the request and returns a response code.
5. The response code is passed back through the kernel to libutee.

The vulnerability is that libutee panics if the response code is unexpected (e.g., TEE_ERROR_CANCEL or TEE_ERROR_OUT_OF_MEMORY). The TEE Internal Core API specification mandates this panic behavior. However, OP-TEE does not sanitize the return code from the REE. An attacker who can stop the legitimate tee-supplicant and run a malicious one can send arbitrary response codes, causing the TA to panic.

For TAs with TA_FLAG_SINGLE_INSTANCE and TA_FLAG_INSTANCE_KEEP_ALIVE, the TA instance persists across sessions, and its memory (including PCR values for fTPM) is preserved. A panic destroys this memory, and when the TA is reloaded, it starts with a clean state. This allows an attacker to reset PCRs and then extend them with arbitrary values, breaking the trust chain.

Vulnerable vs. Patched Code

Vulnerable Code (libutee): In libutee/tee_api_objects.c, the function tee_object_read (or similar) calls __utee_storage_read and checks the return code. If the return code is not TEE_SUCCESS, it calls TEE_Panic. The return code comes directly from the REE without validation.

// Vulnerable pseudo-code
TEE_Result tee_object_read(...) {
    TEE_Result res = __utee_storage_read(...);
    if (res != TEE_SUCCESS) {
        TEE_Panic(res); // Panics on any non-success code
    }
    return res;
}

Patched Code: The fix in commit 941a58d78c99c4754fbd4ec3079ec9e1d596af8f sanitizes the return code from the REE. It maps unexpected codes to a safe error (e.g., TEE_ERROR_GENERIC) before passing to libutee.

// Patched pseudo-code
TEE_Result tee_object_read(...) {
    TEE_Result res = __utee_storage_read(...);
    // Sanitize: only allow expected codes
    if (res != TEE_SUCCESS && res != TEE_ERROR_ITEM_NOT_FOUND) {
        res = TEE_ERROR_GENERIC; // Prevent panic
    }
    if (res != TEE_SUCCESS) {
        TEE_Panic(res); // Now only panics on safe errors
    }
    return res;
}

Exploitation & Lab Setup

Red Team

Prerequisites:

• REE userspace access (root or sufficient permissions to stop/start tee-supplicant).
• Ability to compile a malicious tee-supplicant.

Steps:

1. Identify the target TA: Use tee-supplicant -l or check /dev/teepriv to list TAs. Look for fTPM or other keep-alive TAs.
2. Stop the legitimate tee-supplicant: systemctl stop tee-supplicant or killall tee-supplicant.
3. Deploy malicious tee-supplicant: Write a program that intercepts storage requests and returns unexpected codes (e.g., TEE_ERROR_CANCEL).
4. Trigger TA panic: The TA will call a Secure Storage function, receive the malicious code, and panic.
5. For fTPM: After panic, the fTPM TA reloads with reset PCRs. Extend PCRs with arbitrary values to falsify measurements.

Example malicious tee-supplicant (pseudo-code):

#include <stdio.h>
#include <tee_client_api.h>

int main() {
    // Listen for storage requests
    while (1) {
        // Receive request from kernel
        // Respond with unexpected code
        send_response(TEE_ERROR_CANCEL);
    }
    return 0;
}

Blue Team

Detection:

• Monitor for unexpected termination of tee-supplicant.
• Log TA panics from OP-TEE kernel (check dmesg for "TA panic" messages).
• Use the YARA/Sigma rules below.

Prevention:

• Apply the patch from commit 941a58d78c99c4754fbd4ec3079ec9e1d596af8f.
• Restrict permissions on /dev/teepriv and /dev/tee* to only trusted users.
• Use SELinux or AppArmor to confine tee-supplicant.
• Enable kernel auditing for tee-supplicant process changes.

Indicators of Compromise (IOCs)

• Process: Unexpected tee-supplicant process (check PID, binary path).
• Logs: Kernel messages: TA panic or Unexpected return code from REE.
• File: Modified /usr/sbin/tee-supplicant or custom binary in /tmp.
• Network: No network IOCs (local attack).
• System: TA instances restarting unexpectedly (check /sys/kernel/security/optee/).

Detection Engineering

YARA Rule

rule CVE_2025_46733_OP_TEE_Panic {
    meta:
        description = "Detects malicious tee-supplicant binary that sends unexpected return codes"
        author = "Valters IT"
        date = "2025-04-01"
        reference = "CVE-2025-46733"
    strings:
        $panic_code = { TEE_ERROR_CANCEL } // Hex for TEE_ERROR_CANCEL (0xFFFF0001)
        $storage_api = { __utee_storage_read }
    condition:
        $panic_code and $storage_api
}

Sigma Rule

title: CVE-2025-46733 - OP-TEE TA Panic via Malicious tee-supplicant
id: 8a2b3c4d-5e6f-7a8b-9c0d-1e2f3a4b5c6d
status: experimental
description: Detects TA panics caused by unexpected return codes from REE tee-supplicant
author: Valters IT
logsource:
    product: linux
    service: kernel
detection:
    selection:
        - "TA panic"
        - "Unexpected return code from REE"
    condition: selection
falsepositives:
    - Legitimate TA bugs (rare)
level: high

Suricata Rule

alert ip any any -> any any (msg:"CVE-2025-46733 - OP-TEE TA Panic via Malicious tee-supplicant"; content:"TA panic"; sid:1000001; rev:1;)

Remediation & Mitigation

Immediate:

• Apply the patch from commit 941a58d78c99c4754fbd4ec3079ec9e1d596af8f.
• If patching is not possible, restrict access to tee-supplicant to root only.
• Disable keep-alive TAs if not needed (e.g., fTPM).

Long-term:

• Implement input validation for all REE-to-TEE communication.
• Use signed TAs and verify integrity before loading.
• Monitor for TA panics and alert on anomalies.

Workaround:

• For fTPM, consider using a hardware TPM instead of fTPM.

Valters IT
DevSecOps & Cyber Threat Intelligence