| CVE |
Vendors |
Products |
Updated |
CVSS v3.1 |
| Improper restriction of operations in the IOMMU could allow a malicious hypervisor to access guest private memory resulting in loss of integrity. |
| Improper handling of direct memory writes in the input-output memory management unit could allow a malicious guest virtual machine (VM) to flood a host with writes, potentially causing a fatal machine check error resulting in denial of service. |
| 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. |
| Insufficient bounds checking in AMD TEE (Trusted Execution Environment) could allow an attacker with a compromised userspace to invoke a command with malformed arguments leading to out of bounds memory access, potentially resulting in loss of integrity or availability. |
| An integer overflow in the SMU could allow a privileged attacker to potentially write memory beyond the end of the reserved dRAM area resulting in loss of integrity or availability. |
| A DLL hijacking vulnerability in Vivado could allow a local attacker to achieve privilege escalation, potentially resulting in arbitrary code execution. |
| A bug within some AMD CPUs could allow a local admin-privileged attacker to run a SEV-SNP guest using stale TLB entries, potentially resulting in loss of data integrity. |
| In AMD Zynq UltraScale+ devices, the lack of address validation when executing CSU runtime services through the PMU Firmware can allow access to isolated or protected memory spaces resulting in the loss of integrity and confidentiality. |
| Inadequate lock protection within Xilinx Run time may allow a local attacker to trigger a Use-After-Free condition potentially resulting in loss of confidentiality or availability |
| 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. |
| 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 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 input validation in the AMD Graphics Driver could allow an attacker to supply a specially crafted pointer, potentially leading to arbitrary writes or denial of service. |
| Improper input validation within the XOCL driver may allow a local attacker to generate an integer overflow condition, potentially resulting in crash 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 Protection Against Voltage and Clock Glitches in FPGA devices, could allow an attacker with physical access to undervolt the platform resulting in a 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 input validation within RAS TA Driver can allow a local attacker to access out-of-bounds memory, potentially resulting in a denial-of-service condition. |
| Improper isolation of shared resources on System-on-a-chip (SOC) could a privileged attacker to tamper with the contents of the PSP reserved DRAM region potentially resulting in loss of confidentiality and integrity. |
| 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. |
