| CVE |
Vendors |
Products |
Updated |
CVSS v3.1 |
| Incorrect default permissions in AMD StoreMI™ could allow an attacker to achieve privilege escalation potentially resulting in arbitrary code execution. |
| Improper validation of an array index in the AND power Management Firmware could allow a privileged attacker to corrupt AGESA memory potentially leading to a loss of integrity. |
| Improper input validation in AMD Power Management Firmware (PMFW) could allow a privileged attacker from Guest VM to send arbitrary input data potentially causing a GPU Reset condition. |
| A NULL pointer dereference in AMD Crash Defender could allow an attacker to write a NULL output to a log file potentially resulting in a system crash and loss of availability. |
| 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. |
| Insufficient or Incomplete Data Removal in Hardware Component in SEV firmware doesn't fully flush IOMMU. This can potentially lead to a loss of confidentiality and integrity in guest memory. |
| Improper access control in AMD Secure Encrypted Virtualization (SEV) firmware could allow a malicious hypervisor to bypass RMP protections, potentially resulting in a loss of SEV-SNP guest memory integrity. |
| Improper access control within AMD SEV-SNP could allow an admin privileged attacker to write to the RMP during SNP initialization, potentially resulting in a loss of SEV-SNP guest memory integrity. |
| Improper system call parameter validation in the Trusted OS may allow a malicious driver to perform mapping or unmapping operations on a large number of pages, potentially resulting in kernel memory corruption. |
| Improper input validation in the SMM handler could allow an attacker with Ring0 access to write to SMRAM and modify execution flow for S3 (sleep) wake up, potentially resulting in arbitrary code execution. |
| The security state of the calling processor into Trusted Firmware (TF-A) is not used and could potentially allow non-secure processors access to secure memories, access to crypto operations, and the ability to turn on and off subsystems within the SOC. |
| Insufficient parameter sanitization in TEE SOC Driver could allow an attacker to issue a malformed DRV_SOC_CMD_ID_SRIOV_SPATIAL_PART and cause read or write past the end of allocated arrays, potentially resulting in a loss of platform integrity or denial of service. |
| Missing Checks in certain functions related to RMP initialization can allow a local admin privileged attacker to cause misidentification of I/O memory, potentially resulting in a loss of guest memory integrity |
| Improper cleanup in AMD CPU microcode patch loading could allow an attacker with local administrator privilege to load malicious CPU microcode, potentially resulting in loss of integrity of x86 instruction execution. |
| Improper Hardware reset flow logic in the GPU GFX Hardware IP block could allow a privileged attacker in a guest virtual machine to control reset operation potentially causing host or GPU crash or reset resulting in denial of service. |
| Improper isolation of shared resources on a system on a chip by a malicious local attacker with high privileges could potentially lead to a partial loss of integrity. |
| Improper input validation in the SMM communications buffer could allow a privileged attacker to perform an out of bounds read or write to SMRAM potentially resulting in loss of confidentiality or integrity. |
| Write what were condition within AMD CPUs may allow an admin-privileged attacker to modify the configuration of the CPU pipeline potentially resulting in the corruption of the stack pointer inside an SEV-SNP guest. |
| Insufficient validation within Xilinx Run Time framework could allow a local attacker to escalate privileges from user space to kernel space, potentially compromising confidentiality, integrity, and/or availability. |
| The Secure Flag passed to Versal™ Adaptive SoC’s Trusted Firmware for Cortex®-A processors (TF-A) for Arm’s Power State Coordination Interface (PSCI) commands were incorrectly set to secure instead of using the processor’s actual security state. This would allow the PSCI requests to appear they were from processors in the secure state instead of the non-secure state. |
