What is the CVSS score of CVE-2026-40290?

CVE-2026-40290 has a CVSS 3.1 base score of 7.8 (High). CVSS vector: CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H. EPSS exploitation probability: 0.0%.

Which versions of OP-TEE OS are affected by CVE-2026-40290?

OP-TEE OS versions 3.16.0 through 4.10.x contain a use-after-free race condition affecting the Trusted Execution Environment that allows local low-privileged attackers to corrupt memory in the secure…. A patch is available.

How to fix or mitigate CVE-2026-40290?

Within 24 hours: Identify and inventory all systems and devices running OP-TEE 3.16.0 through 4.10.x; assess operational criticality of each deployment. Within 7 days: Establish a remediation timeline, monitor OP-TEE security advisories and vendor channels for patch announcements, and document current deployment configurations. Within 30 days: Deploy compensating controls including local access restriction policies, kernel-level process isolation (SELinux/AppArmor), and runtime monitoring for exploitation attempts.

OP-TEE OS CVE-2026-40290

EUVD-2026-34139 HIGH

Use After Free (CWE-416)

2026-06-03 GitHub_M

Information Disclosure Use After Free Memory Corruption Linux

7.8

CVSS 3.1 · GitHub Advisory

Severity by source

GitHub Advisory PRIMARY

7.8 HIGH

AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H

Primary rating from GitHub Advisory · only source for this CVE.

CVSS VectorGitHub Advisory

CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H

Attack Vector

Local

Attack Complexity

Low

Privileges Required

Low

User Interaction

None

Scope

Unchanged

Confidentiality

High

Integrity

High

Availability

High

Lifecycle Timeline

Patch available

Jun 03, 2026 - 19:01 EUVD

Analysis Generated

Jun 03, 2026 - 18:20 vuln.today

CVE Published

Jun 03, 2026 - 16:45 nvd

HIGH 7.8

DescriptionGitHub Advisory

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.

AnalysisAI

Use-after-free race condition in OP-TEE OS versions 3.16.0 through 4.10.x enables local low-privileged attackers to corrupt memory within the secure world when OP-TEE is built as an FF-A Secure Partition Manager Core (SPMC) for S-EL0 Secure Partitions. The flaw stems from missing lock acquisition in sp_mem_remove() during shared-memory teardown, allowing concurrent threads to dereference freed sp_mem_map_region or sp_mem_receiver objects. No public exploit identified at time of analysis, but successful exploitation yields high confidentiality, integrity, and availability impact inside the Trusted Execution Environment.

Technical ContextAI

OP-TEE OS is the open-source Trusted Execution Environment that runs in Arm TrustZone secure world alongside a non-secure Linux kernel on Cortex-A cores. The bug lives in the Firmware Framework for Arm (FF-A) shared-memory handling, specifically the SPMC/SP code path activated only when CFG_SECURE_PARTITION=y, used for hosting S-EL0 Secure Partitions. The root cause is CWE-416 (Use After Free) caused by a locking discipline violation: sp_mem_remove() frees entries from smem->receivers and smem->regions without holding the global sp_mem_lock, while sp_mem_get_receiver() iterates these lists without any lock and sp_mem_is_shared() holds the lock but is not serialized against the unprotected free, producing a classic time-of-check / time-of-use dangling-pointer race across concurrent secure-world threads. The affected CPE is cpe:2.3:a:op-tee:optee_os:*:*:*:*:*:*:*:* covering all builds from 3.16.0 up to but not including 4.11.0.

RemediationAI

Vendor-released patch: OP-TEE OS 4.11.0, which adds proper sp_mem_lock acquisition around the free operations in sp_mem_remove(); upgrade affected builds to 4.11.0 or later as described in https://github.com/OP-TEE/optee_os/security/advisories/GHSA-332c-xr93-849m. If immediate upgrade is not feasible, the most direct compensating control is to rebuild OP-TEE with CFG_SECURE_PARTITION=n to remove the vulnerable SPMC/SP code path entirely, with the trade-off that any S-EL0 Secure Partitions hosted by OP-TEE will no longer function and FF-A-based SP workloads must be migrated or disabled. Additionally restrict which non-secure-world components and TAs can invoke FF-A shared-memory share/reclaim operations to reduce the set of actors able to drive concurrent sp_mem_remove() versus iteration paths, accepting that this narrows but does not eliminate the race window.