Improper removal of sensitive information before storage or transfer in AMD Crash Defender could allow an attacker to obtain kernel address information potentially resulting in loss of confidentiality.

Insufficient parameter validation while allocating process space in the Trusted OS (TOS) may allow for a malicious userspace process to trigger an integer overflow, leading to a potential denial of service.

Improper syscall input validation in ASP (AMD Secure Processor) may force the kernel into reading syscall parameter values from its own memory space allowing an attacker to infer the contents of the kernel memory leading to potential information disclosure.

Improper handling of parameters in the AMD Secure Processor (ASP) could allow a privileged attacker to pass an arbitrary memory value to functions in the trusted execution environment resulting in arbitrary code execution

Improper handling of insufficiency privileges in the ASP could allow a privileged attacker to modify Translation Map Registers (TMRs) potentially resulting in loss of confidentiality or integrity.

Improper validation of an array index in the AMD graphics driver software could allow an attacker to pass malformed arguments to the dynamic power management (DPM) functions resulting in an out of bounds read and loss of availability.

Failure to validate the address and size in TEE (Trusted Execution Environment) may allow a malicious x86 attacker to send malformed messages to the graphics mailbox resulting in an overlap of a TMR (Trusted Memory Region) that was previously allocated by the ASP bootloader leading to a potential loss of integrity.

GPU kernel implementations susceptible to memory leak

A GPU kernel can read sensitive data from another GPU kernel (even from another user or app) through an optimized GPU memory region called _local memory_ on various architectures.