| CVE |
Vendors |
Products |
Updated |
CVSS v3.1 |
| A DLL hijacking vulnerability in Vivado could allow a local attacker to achieve privilege escalation, potentially resulting in arbitrary code execution. |
| Improper input validation in AMD Graphics Driver could allow a local attacker to write out of bounds, potentially resulting in loss of integrity or denial of service. |
| Improper access control in secure encrypted virtualization (SEV) could allow a privileged attacker to write to the reverse map page (RMP) during secure nested paging (SNP) initialization, potentially resulting in a loss of guest memory confidentiality and 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. |
| 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. |
| When SMT is enabled, certain AMD processors may speculatively execute instructions using a target
from the sibling thread after an SMT mode switch potentially resulting in information disclosure. |
| A Time-of-check time-of-use (TOCTOU) race condition in the AMD Secure Processor (ASP) could allow an attacker to modify External Global Memory Interconnect Trusted Agent (XGMI TA) commands as they are processed potentially resulting in loss of confidentiality, integrity, or availability. |
| A Time-of-check time-of-use (TOCTOU) race condition in the AMD Secure Processor (ASP) could allow an attacker to corrupt memory resulting in loss of integrity, confidentiality, or availability. |
| A DLL hijacking vulnerability in the AMD Manageability API could allow an attacker to achieve privilege escalation, potentially resulting in arbitrary code execution. |
| Incorrect default permissions in the AMD Manageability API could allow an attacker to achieve privilege escalation, potentially resulting in arbitrary code execution. |
| Failure to validate inputs in SMM may allow an attacker to create a mishandled error leaving the DRTM UApp in a partially initialized state potentially resulting in loss of memory integrity. |
| A junction point vulnerability within AMD uProf can allow a local low-privileged attacker to create junction points, potentially resulting in arbitrary file deletion or disclosure. |
| Improper input validation within AMD uProf can allow a local attacker to write out of bounds, potentially resulting in a crash or denial of service |
| Improper input validation within AMD uprof can allow a local attacker to overwrite MSR registers, potentially resulting in crash or denial of service. |
| Improper return value within AMD uProf can allow a local attacker to bypass KSLR, potentially resulting in loss of confidentiality or availability. |
| Improper input validation within AMD uprof can allow a local attacker to write to an arbitrary physical address, potentially resulting in crash or denial of service. |
| In the Linux kernel, the following vulnerability has been resolved:
drm/amd/display: fix a Null pointer dereference vulnerability
[Why]
A null pointer dereference vulnerability exists in the AMD display driver's
(DC module) cleanup function dc_destruct().
When display control context (dc->ctx) construction fails
(due to memory allocation failure), this pointer remains NULL.
During subsequent error handling when dc_destruct() is called,
there's no NULL check before dereferencing the perf_trace member
(dc->ctx->perf_trace), causing a kernel null pointer dereference crash.
[How]
Check if dc->ctx is non-NULL before dereferencing.
(Updated commit text and removed unnecessary error message)
(cherry picked from commit 9dd8e2ba268c636c240a918e0a31e6feaee19404) |
| Improper initialization of variables in the DXE driver may allow a privileged user to leak sensitive information via local access. |
| Improper initialization of variables in the DXE driver may allow a privileged user to leak sensitive information via local access. |
| 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. |
