A malicious or compromised UApp or ABL could potentially change the value that the ASP uses for its reserved DRAM, to one outside of the fenced area, potentially leading to data exposure.
Insufficient check of the process type in Trusted OS (TOS) may allow an attacker with privileges to enable a lesser privileged process to unmap memory owned by a higher privileged process resulting in a denial of service.
A malicious or compromised UApp or ABL may be used by an attacker to issue a malformed system call to the Stage 2 Bootloader potentially leading to corrupt memory and code execution.
Insufficient DRAM address validation in System Management Unit (SMU) may result in a DMA (Direct Memory Access) read/write from/to invalid DRAM address that could result in denial of service.
A malicious or compromised User Application (UApp) or AGESA Boot Loader (ABL) could be used by an attacker to exfiltrate arbitrary memory from the ASP stage 2 bootloader potentially leading to information disclosure.
A malicious or compromised UApp or ABL may be used by an attacker to issue a malformed system call which results in mapping sensitive System Management Network (SMN) registers leading to a loss of integrity and availability.
An attacker, who gained elevated privileges via some other vulnerability, may be able to read data from Boot ROM resulting in a loss of system integrity.
A malicious or compromised UApp or ABL may be used by an attacker to send a malformed system call to the bootloader, resulting in out-of-bounds memory accesses.
Insufficient bound checks in the System Management Unit (SMU) may result in a system voltage malfunction that could result in denial of resources and/or possibly denial of service.
Insufficient General Purpose IO (GPIO) bounds check in System Management Unit (SMU) may result in access/updates from/to invalid address space that could result in denial of service.