CVE-2026-40290 in optee_os
Summary
by MITRE • 06/03/2026
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. Starting in version 3.16.0 and prior to 4.11.0, a user-after-free (UAF) race condition exists in the shared memory teardown logic of FF-A within OP-TEE SPMC/SP flows. This only applies when OP-TEE is configured as an SPMC for S-EL0 SPs, that is, with `CFG_SECURE_PARTITION=y`. The function `sp_mem_remove()`, responsible for freeing entries in `smem->receivers` and `smem->regions`, fails to acquire the global `sp_mem_lock` before performing the `free()` operations. Concurrently, other code paths, such as `sp_mem_get_receiver()`, iterate over these same lists without holding a lock, or, like `sp_mem_is_shared()`, iterate while holding the lock but are not serialized against the unprotected `free()` in `sp_mem_remove()`. This creates a cross-thread race where a thread iterating the list can acquire a pointer to an entry (e.g., `struct sp_mem_map_region` or `struct sp_mem_receiver`), and then another thread calls `sp_mem_remove()`, freeing the object. When the first thread resumes and dereferences the pointer, it results in a Use-After-Free vulnerability. Version 4.11.0 fixes the issue.
If you want to get the best quality for vulnerability data then you always have to consider VulDB.
Analysis
by VulDB Data Team • 06/03/2026
The vulnerability described represents a critical race condition in OP-TEE's Trusted Execution Environment implementation that affects versions 3.16.0 through 4.10.0. This issue specifically targets the FF-A (Future Firmware Architecture) shared memory management within the SPMC (Secure Partition Manager Controller) and Secure Partitions flows. The vulnerability manifests when OP-TEE operates in S-EL0 SP (Secure Partition) mode with the configuration parameter CFG_SECURE_PARTITION=y, creating a complex multi-threaded scenario where memory management operations conflict with concurrent access patterns. The core problem lies in the improper synchronization of memory deallocation operations within the shared memory teardown logic, which directly impacts the security guarantees of the TrustZone environment.
The technical flaw occurs in the function sp_mem_remove() which handles the cleanup of shared memory entries in the smem->receivers and smem->regions data structures. This function fails to acquire the global sp_mem_lock before executing free() operations on memory objects, creating a fundamental race condition between different execution threads. Concurrent code paths such as sp_mem_get_receiver() traverse these same data structures without proper locking mechanisms, while sp_mem_is_shared() performs iterations while holding the lock but fails to serialize against the unprotected free() calls in sp_mem_remove(). This creates a classic user-after-free scenario where one thread may successfully acquire a pointer to a memory entry during iteration, while another thread simultaneously executes the free() operation on that same entry, resulting in a dangling pointer reference. The vulnerability specifically targets the struct sp_mem_map_region and struct sp_mem_receiver data types, making it particularly dangerous for memory corruption attacks.
The operational impact of this vulnerability extends beyond simple memory corruption, as it represents a serious threat to the integrity and security of the entire TrustZone execution environment. Attackers could potentially exploit this race condition to execute arbitrary code within the TEE context, bypassing the security boundaries that TrustZone is designed to enforce. The vulnerability affects the fundamental shared memory management capabilities of OP-TEE, which are essential for secure communication between the secure and non-secure worlds. Given that this flaw exists in the SPMC/SP flows that handle secure partition management, successful exploitation could lead to privilege escalation, data leakage, or complete compromise of the trusted execution environment. The timing and complexity of the race condition make detection and exploitation challenging, but the potential consequences are severe enough to warrant immediate remediation.
The fix implemented in version 4.11.0 addresses the root cause by ensuring proper locking mechanisms are enforced in the sp_mem_remove() function, requiring acquisition of the sp_mem_lock before any free() operations occur. This resolves the race condition by serializing access to the shared memory data structures, preventing concurrent access patterns that led to the user-after-free condition. The mitigation aligns with established security practices for concurrent programming and memory management, specifically addressing CWE-362 (Concurrent Execution using Shared Resource with Improper Synchronization) and CWE-416 (Use After Free). From an ATT&CK framework perspective, this vulnerability would map to T1548.003 (Abuse Elevation of Privilege: Domain Transition) and T1059.001 (Command and Scripting Interpreter: Visual Basic) if exploited through command injection vectors. Organizations should immediately upgrade to OP-TEE version 4.11.0 or later to prevent exploitation, while also implementing monitoring for anomalous memory access patterns in TEE environments. The vulnerability underscores the critical importance of proper synchronization in multi-threaded security-critical code and demonstrates how seemingly minor locking issues can have catastrophic security implications in trusted execution environments.