Description

Kernel software from a non-secure operating system on a platform with Trusted Execution Environment support, may cause GPU Firmware to boot up using data from non-secure memory. The GPU thread of control (Firmware) uses a pointer from non-secure memory belonging to the Rich Execution Environment (REE) when saving or retrieving internal data between the tightly coupled private memory to main memory. An attacker with control over the REE kernel may modify the pointer value, corrupting the data used by the GPU Firmware.

Executive Summary

Technical Details

Mitigations

References

Additional Metadata

{
  "score": "7.8",
  "pubDate": "2026-08-07T03:16:19.810Z",
  "pubdate": "2026-08-07T03:16:19.810Z",
  "executiveSummary": "This vulnerability involves an insecure memory management flaw where kernel software from a non-secure operating system allows GPU Firmware to boot using data sourced from non-secure memory on platforms equipped with a Trusted Execution Environment support.\nThe core issue stems from the GPU thread of control utilizing an untrusted pointer originating from the Rich Execution Environment (REE) non-secure memory during context save and restore operations between tightly coupled private memory and main memory.\nAn attacker possessing control over the REE kernel can manipulate this pointer value, leading to critical data corruption within the GPU Firmware execution context.\nThe potential impact includes arbitrary data corruption, compromise of the GPU subsystem integrity, and potential escalation of privileges across the privilege boundary between the Rich Execution Environment and the Trusted Execution Environment.\nExploitation requires the attacker to already possess privileged code execution within the non-secure REE kernel to alter the insecure pointer values consumed by the secure GPU firmware.\nAffected systems are restricted to platforms featuring a Trusted Execution Environment and GPU architectures that improperly validate memory pointers supplied across the non-secure to secure boundary during initialization and runtime operations.",
  "technicalDetails": "The vulnerability resides in the interface handling between the Rich Execution Environment (REE) kernel and the GPU Firmware subsystem operating on a hardware platform with Trusted Execution Environment (TEE) support.\nThe root cause is the unvalidated and implicit trust placed in pointers supplied by the non-secure REE kernel during the GPU Firmware boot sequence and ongoing runtime state management.\nSpecifically, when the GPU thread of control—functioning as firmware—saves or retrieves internal operational data between its tightly coupled private memory and main memory, it references a memory pointer originating from non-secure REE memory.\nBecause this pointer is passed without rigorous cryptographic or hardware-enforced boundary validation from the secure domain, an adversary with compromise of the REE kernel possesses the capability to modify the pointer value.\nThe step-by-step attack flow proceeds as follows: First, the attacker compromises the non-secure REE kernel to attain high-privilege code execution in the non-secure operating system. Second, during GPU initialization or routine context-switching operations, the GPU Firmware attempts to read or write internal state data using the REE-provided memory pointer. Third, the attacker leverages their control over the REE kernel to alter this pointer to point to arbitrary system memory locations. Fourth, when the GPU Firmware dereferences the malicious pointer to save or retrieve internal data, it reads or writes to unintended memory locations, corrupting critical firmware data structures. Fifth, this data corruption disrupts the normal execution flow of the GPU Firmware, potentially yielding memory corruption, denial of service, or a bypass of security boundaries enforced by the Trusted Execution Environment.\nThe vulnerable components involve the GPU Firmware initialization routines and the data transfer interface bridging the non-secure REE memory and the GPU private memory.\nAuthentication and privilege requirements dictate that the attacker must already execute code with REE kernel-level privileges to manipulate the insecure memory pointers.\nNetwork exposure is not directly applicable, as the attack vector relies on local software control within the host operating system's kernel space."
}