Amd
Monthly
Attacker-controlled pointer dereference in AMD's ROCm Communication Collectives Library (RCCL) can escalate to remote code execution when a compromised peer rank - or a network-adjacent attacker on the collective fabric - participates in a multi-GPU or multi-node distributed workload. The defect (CWE-822, untrusted pointer dereference) affects RCCL running on AMD Instinct MI200/MI300/MI350-class accelerators and carries a CVSS 4.0 base score of 7.7 (vector AV:N/AC:H/AT:N/PR:L/UI:N, High confidentiality/integrity/availability), mapping to an assessed CVSS 3.1 of AV:N/AC:H/PR:L/UI:N/S:U/C:H/I:H/A:H. Exploitation is not confirmed as active (CVE is not in CISA KEV) and no public exploit code has been identified at time of analysis; the attack requires a pre-existing foothold as a peer rank inside the collective group rather than anonymous internet access, so this is a moderate-priority issue for distributed AMD GPU deployments rather than an internet-wide emergency.
Use-after-free in the Linux kernel's drm/ttm graphics memory manager (a regression introduced by commit b2ed01e7ad3d, present in roughly 7.0.10 through 7.1 and in stable backports such as Ubuntu 7.0.0-31) allows a locally authenticated user with an active GPU workload to crash the kernel minutes to hours after a swapout event. Because ttm_bo_swapout_cb() skips the bulk_move bookkeeping on successful swapout, a swapped-out resource stays on its buffer object's bulk_move range and on the manager LRU while being unevictable; when it is later freed or the BO leaves the bulk_move, ttm_resource_del_bulk_move() skips it due to its unevictable guard, leaving a dangling cursor that the next ttm_lru_bulk_move_tail() or ttm_resource_add_bulk_move() dereferences. Exploitation requires local presence, an affected AMD/drm-ttm system, and timing-dependent hibernation or memory-pressure conditions (the reporter observed crashes in only 5 of 18 hibernation cycles), and no public exploit code has been identified at time of analysis; EPSS is 0.20% (9th percentile), signalling low near-term exploitation likelihood.
Unauthorized code execution during the boot process is possible on AMD Zynq UltraScale+ MPSoC, Zynq UltraScale+ RFSoC, and Kria SOM devices when an attacker with physical or local USB access can drive oversized Device Firmware Upgrade (DFU) download requests while the device is held in USB boot mode. The flaw is an out-of-bounds write (CWE-787) in the USB boot-mode DFU path: missing boundary validation allows the download to overflow the DDR receive buffer and corrupt adjacent First Stage Boot Loader (FSBL) memory before the FSBL hands off to later boot stages. AMD rates this 7.5 (CVSS 4.0 AV:L/AC:L/AT:P/PR:N/UI:N with High confidentiality, integrity, and availability impact to the device); no public exploit code and no confirmed active exploitation were identified at time of analysis, and practical exposure is limited to devices whose boot configuration actually permits USB boot rather than QSPI/eMMC/SD.
Host-controlled AML injection in Edgeless Systems' Contrast confidential-computing runtime before 1.18.0 lets an adversary who controls the QEMU host achieve arbitrary code execution inside AMD SEV-SNP guest VMs, including reads and writes to private memory pages that the confidential-computing model is supposed to shield. Only the Metal-QEMU-SNP and Metal-QEMU-SNP-GPU platforms are affected; Metal-QEMU-TDX is not, because OVMF measures ACPI table contents into RTMR 0 on Intel TDX. The flaw is rated CVSS 8.4 (CVSS:4.0/AV:L/AC:L/AT:N/PR:L/UI:N/VC:H/VI:H/VA:N) via the host-to-guest trust boundary, carries no CISA KEV status and no public exploit code identified at time of analysis, and is fixed in Contrast 1.18.0, which sandboxes the kernel AML interpreter; the underlying BadAML technique is publicly documented in academic and Black Hat EU 2024 research, and the weakness is generic to Confidential Computing deployments that expose the ACPI interface to the host.
A kernel error-handling bug in the AMD IOMMU nested-domain allocation path of the Linux kernel (7.x, AMD-Vi/vIOMMU systems) causes domain-ID allocation failures to be silently ignored, so a nested IOMMU domain can be set up using a host domain ID that was never actually allocated. The flaw is reachable only by a locally privileged caller able to create IOMMU domains (iommufd/vIOMMU nested translation) and only when amd_iommu_pdom_id_alloc() actually fails (domain-ID space exhaustion or short memory), so it is a real but difficult-to-trigger error-path defect with no public exploit identified at time of analysis. Notably, the 7.8 NVD-style score (S:C/C:H/I:H/A:H) is inconsistent with the practical impact, which the independent assessment rates as limited integrity and availability gain on the error path only; vendor patches are available.
Page-table corruption can be triggered on LoongArch Linux kernels when the architecture fails to define DIRECT_MAP_PHYSMEM_END, causing get_free_mem_region() and mhp_get_pluggable_range() to fall back to the generic mm.h constant (1ULL << MAX_PHYSMEM_BITS) - 1 instead of the CPU's actual vmemmap-covered range. On LoongArch CPUs whose probed physical address bits (cpu_pabits from CPUCFG1) are fewer than MAX_PHYSMEM_BITS - notably the Loongson-2K series - a ZONE_DEVICE region can be allocated outside the vmemmap window, and vmemmap_populate() then wraps the memmap range around into low memory, silently corrupting page tables. The bug is local (CVSS vector PR:L), requires specific hardware plus CONFIG_SPARSEMEM_VMEMMAP and the ZONE_DEVICE/device-memory or amdkfd code path, and our independent assessment rates it AC:H with only C:L (versus the auto-generated 7.8 score with AC:L/C:H); no public exploit code or CISA KEV entry was identified at time of analysis.
An attestation-freshness and origin-validation failure in the aTLS AMD SEV-SNP verification path of Cocos AI (Ultraviolet) affects versions up to and including 0.8.2: when a relying party invokes the intra-handshake verification path with no expected reportData value (nil, empty, or omitted), the SEV-SNP policy ReportData is left unset and the verifier will accept unrelated or stale Evidence that is not bound to the current TLS connection. An attacker who possesses a valid but foreign or replayed SEV-SNP attestation blob can therefore induce a trusting party to accept an unintended attestation context, undermining the core trust guarantee of the confidential-computing platform and potentially enabling both integrity and confidentiality compromise in any workflow where aTLS output drives a trust or authorization decision. Exploitation is unauthenticated at the network layer (CVSS PR:N) but constrained by high attack complexity and specific prerequisites - the caller must omit the expected reportData, and only SEV-SNP aTLS deployments up to 0.8.2 are exposed; no public exploit code or confirmed active exploitation has been identified at time of analysis. The issue is fixed in version 0.9.0.
A dangling pointer in the Linux kernel's AMD display (amdgpu/DC) plane-reset path allows a locally logged-in, low-privileged user to leave a freed plane-state object referenced, which can crash the kernel. The bug lives in amdgpu_dm_plane_drm_plane_reset(), which freed the old state before allocating its replacement and, when that kzalloc() failed, returned without updating the pointer, so the failure path left a stale reference to released memory. Affected systems are those with an AMD GPU running the amdgpu display core code (Linux 6.0 onward per EUVD data); exploitation is constrained because the dangling pointer only materialises under a precisely timed kernel memory-allocation failure that an attacker cannot reliably force, giving an assessed availability-only impact (CVSS:3.1/AV:L/AC:H/PR:L/UI:N/S:U/C:N/I:N/A:H) rather than code execution. No public exploit code was identified at time of analysis and there is no CISA KEV confirmation; vendor patches are available via the upstream stable commits listed in the references.
A dangling-pointer condition in the AMD display (amdgpu) driver of the Linux kernel can leave a CRTC state pointer referencing freed memory when amdgpu_dm_crtc_reset_state() runs: the function frees the old state before attempting kzalloc() for the replacement, and if that allocation fails it returns without updating the pointer. Systems running AMD GPUs are affected, tracing back to kernel 4.15-era code, with fixes shipped in Linux 7.2.6 and 7.3-rc1. Triggering this requires local access to the amdgpu DRM device plus a carefully timed allocation failure (memory exhaustion), so while the vendor-scored severity is 7.8, the assessed impact is limited to a possible kernel crash (availability only) for a local user with existing device access; no public exploit code has been identified at time of analysis and there is no confirmed active exploitation (not in CISA KEV).
An off-by-one array-sizing bug in the Linux kernel's AMD display driver (drm/amd/display) lets a local low-privileged user trigger an out-of-bounds access to the per-connector MST HDCP arrays when a Multi-Stream Transport topology presents the 32nd connector that DRM core supports; the constant AMDGPU_DM_MAX_DISPLAY_INDEX was 31 but used as a connector count/size, leaving the arrays one element short. Per the independent assessment (CVSS:3.1/AV:L/AC:H/PR:L/UI:N/S:U/C:L/I:L/A:H), exploitation requires an AMD GPU running amdgpu with HDCP over MST and an MST hub/daisy-chain exposing the full 32 connectors, so it is limited by a physical topology precondition and by being a bounded single-element overrun rather than an attacker-sized overflow - systems with one to three displays never reach the vulnerable index. A vendor patch is available (Linux 7.2.6 and 7.3-rc1 stable releases, plus the corresponding upstream commits); no public exploit code exists and no active exploitation has been confirmed (not in CISA KEV).
Missing validation of the plane degamma LUT size in the Linux kernel's AMD display driver (amdgpu/DC) lets a local, authenticated user who can submit DRM atomic commits supply a malformed AMD_PLANE_DEGAMMA_LUT blob - for example a single-entry LUT - and drive the kernel into a divide-by-zero in __is_lut_linear() or an out-of-bounds read in __drm_lut_to_dc_gamma(). The practical consequence is a kernel crash or denial of service and, via the out-of-bounds read, potential disclosure of kernel memory contents; there is no evidence of memory corruption leading to code execution, and this is a local-only issue. Reachability is narrow: the vulnerable property is exposed only on kernels built with AMD_PRIVATE_COLOR (not enabled in mainstream distribution kernels) and only on systems with an AMD GPU using the amdgpu/DC display path. No public exploit code and no confirmed active exploitation were identified at time of analysis, and vendor patches are available in the stable trees (6.12.110, 6.18.51, 7.2.5) and in mainline 7.3-rc1.
Integer overflow in the Linux kernel's amdgpu VCN decode-message parser lets an authenticated local user with access to the AMD GPU device node bypass a buffer-count bounds check and drive the parser loop far past the end of a message buffer object, producing out-of-bounds kernel reads that crash the system (availability) and can disclose kernel memory (confidentiality). Exploitation is not remote or unauthenticated: the attacker must be a local principal able to submit VCN decode messages and must additionally allocate a roughly 4 GiB GPU-accessible mapping so msg[1] passes the earlier 'header does not fit in BO' check, a substantial resource precondition that our assessment scores as high attack complexity (CVSS:3.1/AV:L/AC:H/PR:L/UI:N/S:U/C:H/I:N/A:H). No public exploit code was identified at time of analysis and the issue is not listed as confirmed actively exploited (CISA KEV); this is a genuine but modest-priority local vulnerability.
Linux kernel AMD KFD (amdkfd) SVM migration code can use an uninitialized return value when migrating a VM range whose CPU side is a hole, causing the driver to tear down all VRAM pages it has just allocated and leaving memory state inconsistent. Affected are Linux kernel builds using the AMD GPU compute path (SVM/HMM migration to VRAM on ROCm/HSA-capable AMD hardware); the flaw affects code reachable from the commit 1da177e4c3f41524e886b7f1b8a0c1fc7321cac2 baseline and is fixed in 6.18.51, 7.2.5 and 7.3-rc1. Triggering requires a local user holding a GPU device handle and hitting a racy, non-default memory-layout condition, and no public exploit code was identified at time of analysis; the vendor's CVSS 3.1 score of 7.8 is assessed as overstated relative to this local, condition-gated error-handling defect.
Uninitialized physical address use in the AMD PMC driver (`amd_stb_s2d_init()`) causes the Linux kernel to call `devm_ioremap()` with physical address zero when the SMU rejects a command with error 0xff, mapping the first 16 MB of physical RAM into kernel virtual address space. Affected systems are AMD-based Linux hosts where the System Management Unit returns an error during S2D (System Trace Buffer) initialization at driver probe time. No public exploit exists and EPSS is 0.20%, consistent with the hardware-gated trigger; fixes are available in Linux 6.18.50 and 7.2.4 stable branches.
Incomplete error-path cleanup in the AMD PMC driver (`platform/x86/amd/pmc`) corrupts the kernel's global LPS0 s2idle linked list when `amd_stb_s2d_init()` fails during module probe, leaving a dangling registered handler whose backing `devm`-managed memory has been freed. On AMD-based x86 Linux systems running an affected kernel, this causes a kernel BUG (`list_add corruption`) upon module reload and a use-after-free condition on any subsequent suspend-to-idle (s2idle) transition. No public exploit exists and EPSS is 0.20% (10th percentile), but the failure condition can arise naturally on long-running systems or specific SMU firmware, making this a realistic local denial-of-service and a potential kernel code-execution path on vulnerable AMD hardware.
Use-after-free in the Linux kernel's AMD MP2 I2C driver (i2c-amd-mp2) enables local low-privileged users to corrupt kernel memory, potentially achieving privilege escalation or system crash on AMD hardware. The flaw occurs during driver probe: when i2c_add_adapter() fails, devres frees the platform I2C context, but the MP2 PCI driver retains a stale pointer in its IRQ and system-sleep callback table, allowing subsequent dereference of freed memory. No public exploit exists and EPSS is 0.18% (7th percentile), reflecting the hardware-specific and error-path-dependent nature of this flaw; vendor-released patches are available across all major stable kernel branches.
Incorrect TLB flush address targeting in the Linux kernel's zap_pte_range memory management function exposes systems running kernel versions prior to 7.1.9 and 7.2 to local privilege escalation and information disclosure, particularly on AMD systems with EFER.TCE enabled and Intel systems using INVPCID. A low-privileged local attacker can exploit a race where the kernel flushes the wrong virtual address after freeing a page table, leaving stale CPU paging-structure-cache entries that can be speculatively accessed or cause the freed table to be reused with potentially attacker-controlled data. No public exploit code or active exploitation (CISA KEV) has been confirmed at time of analysis, and the 0.20% EPSS score reflects the complexity of reliable exploitation.
Use-after-free in the Linux kernel's AMD GPU power management subsystem (drm/amd/pm) allows a low-privileged local attacker to corrupt kernel memory via a race condition in the sysfs power table interface. The flaw exists because amdgpu_dpm_get_pp_table() returns a raw pointer to a driver-owned buffer after releasing adev->pm.mutex, enabling a concurrent pp_table write to free the allocation while a sysfs copy is still in progress. No public exploit has been identified and EPSS probability is very low (0.15%), but the CVSS 7.8 C:H/I:H/A:H impact reflects credible potential for local privilege escalation or kernel crash on AMD GPU-equipped Linux systems.
Divide-by-zero panic in the Linux kernel's AMD display driver (drm/amd/display) allows a low-privileged local user to crash the kernel by triggering a zero-area viewport condition in the calculate_mcache_setting function. The vulnerable code path exits early with num_mcaches == 0 and mvmpg_width/height == 0, then proceeds to divide by those zero values, causing both a divide-by-zero panic and potential integer underflow on num_mcaches. EPSS is very low at 0.15% (5th percentile) and no active exploitation or public exploit code has been identified at time of analysis; however, the local trigger mechanism via display mode setting is accessible to low-privileged users on systems with AMD GPU hardware.
Out-of-bounds slab read in the Linux kernel's ASoC AMD ACP SoundWire legacy machine driver allows a local attacker - or a hardware-triggered probe path - to read beyond an allocated array in create_sdw_dailinks(), potentially causing kernel memory disclosure or denial of service. The vulnerability is introduced when all DAI link entries are initialized, causing the boundary-unchecked loop to walk past the end of the soc_dais allocation. KASAN confirmed the read-of-size-1 in mc_probe(). EPSS is at 0.17% (6th percentile) and the vulnerability is not listed in CISA KEV; no public exploit has been identified at time of analysis. Fixes are available for Linux stable branches 6.18.40 and 7.1.5, as well as the 7.2-rc1 mainline.
Out-of-bounds array read in the Linux kernel's AMD ACP SoundWire SOF audio driver exposes kernel memory to local attackers on systems equipped with AMD SoundWire hardware. The flaw in create_sdw_dailinks() allows iteration past the end of the allocated sof_dais array when all entries are initialized, lacking any bounds guard on the loop termination condition. No active exploitation is recorded (EPSS 0.17%, 6th percentile; no CISA KEV entry), and patches are available across multiple Linux stable branches.
Kernel page fault in Linux kernel AppArmor's file auditing path allows a local low-privileged user to crash the system or leak kernel memory via the audit log. The regression was introduced by commit 4a134723f9f1, which left the *name pointer uninitialized when path->dentry is the aa_null sentinel, then passed it to audit_log_untrustedstring() where strlen() dereferences an invalid address. No public exploit code exists and EPSS probability is 0.17% (7th percentile), but patched stable releases 6.18.40, 7.1.5, and 7.2-rc1 are confirmed available.
Timing side-channel in AMD Vitis Libraries' ECDSA secp256k1 Security Module exposes private cryptographic keys to local attackers via statistical analysis of operation timing or electromagnetic emanations. Affected are versions prior to 2026.1 of the Vitis Libraries Security Module and Vitis Unified Installer for FPGAs and Adaptive SoCs on Windows. AMD has released version 2026.1 as the fix; no public exploit or active exploitation has been identified at time of analysis.
Use-after-free in the Linux kernel AMD IOMMU driver allows a local low-privileged attacker on multi-CPU AMD systems to corrupt kernel memory by exploiting a logical race in `iommu_completion_wait()`. The `need_sync` flag was read locklessly, enabling a CPU to return without waiting for hardware IOMMU command completion while another CPU's page-table pages are freed - leaving the IOMMU walking stale, potentially freed memory. No public exploit exists and EPSS is 0.20% (10th percentile), but successful exploitation on AMD virtualization infrastructure could cross IOMMU isolation boundaries affecting co-tenant VMs.
Double-free and use-after-free conditions in the Linux kernel's drm/amd/display subsystem expose systems with AMD GPU hardware to potential privilege escalation or kernel crash. The flaw resides in dm_update_crtc_state(), where the skip_modeset path releases a display stream reference without nullifying the pointer, leaving it dangling for a second release if a subsequent error - such as a color management failure - triggers the fail label. Patches are confirmed across multiple stable branches (6.6.148, 6.12.101, 6.18.42, 7.1.6, and 7.2-rc4); no public exploit exists and EPSS sits at 0.17% (6th percentile), but the kernel-level memory corruption class demands prioritized patching on AMD GPU deployments.
A stack buffer overflow in the AMD display driver (dc_process_dmub_aux_transfer_async) within the Linux kernel allows a local authenticated attacker with low privileges to potentially execute arbitrary code or crash the system. The flaw arises from missing bounds checks on payload length and link_index, impacting all kernels before the patched versions. While no active exploitation or public proof-of-concept is reported, the issue affects a wide range of systems with AMD GPUs.
Out-of-bounds read in the Linux kernel's AMD IOMMU debugfs subsystem exposes local users with standard privileges to potential kernel memory disclosure or denial of service via a sign-extension defect. The functions iommu_mmio_write() and iommu_capability_write() declare offset variables as signed int but populate them with kstrtou32_from_user(), allowing values in the range 0x80000000-0xFFFFFFFF to wrap negative and theoretically index before the intended MMIO region. The vulnerability description explicitly characterizes it as latent, acknowledging that three pre-existing defensive layers already prevent exploitation in practice; the fix replaces the unsigned parser with kstrtos32_from_user() and adds explicit negativity checks. No public exploit exists, no KEV listing is present, and EPSS sits at 0.15% (5th percentile).
Denial of service in the Linux kernel's KVM/SVM AVIC (Advanced Virtual Interrupt Controller) IPI virtualization affects Hygon Family 18h hosts, where a hardware erratum (#1235, shared with AMD Zen1 Family 17h) lets the CPU read a stale IsRunning bit during ICR write emulation and skip the expected AVIC_IPI_FAILURE_TARGET_NOT_RUNNING VM-Exit. As a result KVM misses the wakeup of a blocking target vCPU, causing hung vCPUs and unbounded stalls in guest execution. EPSS is low (0.17%, 6th percentile) and there is no public exploit identified at time of analysis; the fix disables AVIC IPI virtualization on these CPUs so every non-self IPI is correctly emulated via VM-Exit.
Out-of-bounds read in the AMD display (amdgpu) driver of the Linux kernel occurs when the GPIO pin table parsers get_gpio_i2c_info() and bios_parser_get_gpio_pin_info() trust the VBIOS table_header.structuresize field and iterate over gpio_pin[] entries without confirming the full claimed size is mapped. On a system with a malformed or oversized VBIOS structuresize, the loop reads past the end of the BIOS image, potentially disclosing adjacent kernel memory or crashing the driver. There is no public exploit identified at time of analysis, EPSS is low (0.17%), and the issue is not listed in CISA KEV; a vendor patch is available across multiple stable trees.
Out-of-bounds read in the Linux kernel's AMD Display (amdgpu DRM) DisplayPort code allows a local attacker - or a malicious/attacker-controlled DisplayPort sink - to trigger a one-element over-read of the aux_rd_interval[] array in dp_get_eq_aux_rd_interval(). The array in struct dc_lttpr_caps holds only MAX_REPEATER_CNT-1 (7) entries but is indexed with an offset up to MAX_REPEATER_CNT (8) when a sink advertises 8 LTTPR repeaters via DPCD, reading aux_rd_interval[7]. There is no public exploit identified at time of analysis, EPSS risk is low (0.17%, 6th percentile), and the vendor has released fixed kernel versions.
Heap overflow in the Linux kernel's AMD GPU display driver (drm/amd/display) arises because dal_vector_reserve() computes its allocation size as "capacity * struct_size" in 32-bit arithmetic, which can silently wrap to a small value and cause krealloc() to return an undersized buffer. A local, low-privileged user with access to the DRM/amdgpu device can trigger out-of-bounds heap writes on subsequent vector appends, potentially corrupting kernel memory. There is no public exploit identified at time of analysis, and the EPSS score is low (0.19%, 9th percentile); the issue is fixed and rated CVSS 7.0 (High).
Local privilege escalation and memory corruption in the Linux kernel DRM/GEM subsystem stems from a race condition in the GEM change_handle ioctl when it runs concurrently with gem_close, where botched two-stage idr_replace handling against the wrong idr slot allows a concurrent close to steal the object's only inherited reference. The flaw affects systems using the DRM graphics stack (notably AMD GPU paths, per source tags) and an unprivileged local user with access to a DRM render/card device can trigger a use-after-free, with the upstream resolution disabling the change_handle ioctl entirely until the locking can be proven correct. No public exploit identified at time of analysis and EPSS is low (0.17%, 7th percentile), consistent with a local-only, hard-to-win race rather than mass exploitation.
Out-of-bounds read and unbounded-iteration denial of service in the Linux kernel's AMD Display (amdgpu DC) driver arises when the bios_parser/bios_parser2 code walks VBIOS record chains that lack a proper 0xFF terminator record. A local attacker able to supply a malformed VBIOS image can force hundreds of thousands of probe-time iterations (with record_size=1) and, near the image boundary, trigger struct casts that read past the 2-byte header validated by GET_IMAGE. There is no public exploit identified at time of analysis, and the EPSS score is low (0.17%, 6th percentile), consistent with a local, firmware-dependent memory-safety bug rather than a broadly exploited remote flaw.
Out-of-bounds kernel heap write in the AMD Display (amdgpu) driver's HDMI HDCP 2.x repeater authentication path affects Linux kernels from 5.6 through the 7.1 release candidates. When reading a downstream sink's RxStatus register, the driver in mod_hdcp_read_rx_id_list() uses an attacker-influenced 10-bit message-size field (up to 1023 bytes) as the I2C read length without bounding it to the 177-byte rx_id_list buffer, so a malicious HDMI repeater can force a write past the buffer and corrupt kernel memory. There is no public exploit identified at time of analysis and EPSS is low (0.21%, 11th percentile); it is not listed in CISA KEV.
Out-of-bounds heap write in the Linux kernel amdgpu DRM display driver (drm/amd/display) arises because the VBIOS integrated info tables (v1_11 and v2_1) expose unvalidated u8 HdmiRegNum and Hdmi6GRegNum fields that are used as loop bounds when copying retimer I2C settings into fixed-size arrays (9 and 3 elements). A malformed VBIOS can set these counts up to 255, overrunning the destination arrays during driver probe on AMD GPU systems. No public exploit has been identified and EPSS is very low (0.17%), but the memory-corruption primitive (CWE-787) carries high confidentiality, integrity, and availability impact per the CVSS 7.8 rating.
Improper DMA-alias handling in the Linux kernel's AMD IOMMU driver lets a stale or incorrect Device Table Entry (DTE) be propagated to an alias PCI device, weakening the DMA isolation the IOMMU is meant to enforce. The flaw affects systems on AMD platforms where pci_for_each_dma_alias() supplies an alias-rather than the original-device to clone_alias(), causing the wrong source devid to be used when copying the DTE. EPSS is low (0.17%, 6th percentile) and there is no public exploit identified at time of analysis.
Man-in-the-middle attacks against AMD's optional desktop tools - AMD Management Console (AMC), AMD Ryzen Master, and AMD μProf - can lead to arbitrary code execution because the affected utilities transport data over plaintext HTTP rather than TLS. An attacker positioned on the network path between a victim workstation and the AMD endpoint can tamper with traffic (most plausibly update or telemetry channels) to substitute malicious content that is then executed by the tool. No public exploit identified at time of analysis and the issue is not in CISA KEV; EPSS data was not provided.
Out-of-bounds array access in the Linux kernel's AMD GPU display driver (drm/amd/display) allows local privileged users to trigger memory corruption via the dcn35_stream_encoder_create() function when eng_id equals ENGINE_ID_DIGF (value 5) or is negative, indexing past the 5-element stream_enc_regs[] array. The flaw stems from a faulty boundary check using <= instead of <, and no public exploit has been identified at time of analysis with an EPSS score of 0.02% (5th percentile) indicating very low exploitation probability.
Local privilege escalation and information disclosure in the Linux kernel on AMD Zen2 CPUs allows low-privileged users to trigger instruction corruption via improper isolation of shared resources in the op cache. Affecting kernels prior to 5.10.256, 5.15.207, 6.1.173, 6.6.139, 6.12.88, 6.18.30, and 7.0.7, the flaw carries a CVSS 8.8 due to scope change (S:C) impacting confidentiality, integrity, and availability beyond the original security boundary. EPSS is very low (0.02%, 7th percentile) and no public exploit identified at time of analysis, but the architectural nature of the bug (CPU op cache sharing) makes it relevant for multi-tenant and virtualization workloads.
Denial of service in the Linux kernel Ceph client allows local users with access to a Ceph-mounted filesystem to trigger d_hash list corruption and RCU stalls by inducing path lookups against reused cached negative dentries. The flaw stems from fs/ceph/dir.c calling d_add(dentry, NULL) on already-hashed negative dentries, creating self-loops in the hlist_bl bucket that cause __d_lookup() to spin indefinitely. EPSS is 0.02% (5th percentile) and no public exploit identified at time of analysis, but the bug has been reproduced organically in production (RCU stall on a Dell PowerEdge R7615 running 6.18.17).
Local privilege escalation potential in the Linux kernel's AMD KFD (Kernel Fusion Driver) debug subsystem allows a local user with GPU access to trigger a buffer overflow in the watch_points array via a crafted watch_id value. The flaw stems from signed/unsigned integer mishandling in kfd_dbg_trap_clear_dev_address_watch(), where userspace-supplied watch_id values exceeding INT_MAX cause undefined bit shifts and out-of-bounds memory access. No public exploit identified at time of analysis, and EPSS scores exploitation probability at only 0.02%.
Remote unauthenticated manipulation of AMD Instinct GPU configuration is possible in the AMD Device Metrics Exporter (DME), a ROCm-ecosystem monitoring component, because the service binds to an unrestricted IP address and exposes its control surface network-wide. Any attacker able to reach the listening port can push unauthorized GPU configuration changes, degrading or denying availability of the affected AMD Instinct MI-series accelerator (MI210/MI250/MI250X/MI300A/MI300X/MI308X/MI325X/MI350X/MI355X). No public exploit is identified at time of analysis, and EPSS is low (0.20%), but the CVSS 4.0 base score of 9.2 reflects trivial network reachability with high availability impact.
Insecure installation directory permissions in AMD chipset driver allow local authenticated attackers to achieve SYSTEM-level privilege escalation and execute arbitrary code. The vulnerability affects nearly all AMD Ryzen, Threadripper, EPYC, and Athlon processors across desktop, mobile, embedded, and server product lines. AMD has released patched chipset driver versions 8.01.20.513 (consumer/workstation) and 8.03.14.329/8.03.16.641 (server). No active exploitation confirmed at time of analysis, but the local vector and low attack complexity make this exploitable by any authenticated Windows user, including standard users without admin rights.
AMD IOMMU completion wait operations in the Linux kernel can trigger soft lockups under high load when strict mode is enabled (iommu.strict=1). The vulnerability stems from busy-waiting inside a spinlock with interrupts disabled, causing kernel responsiveness issues and potential denial of service on systems with AMD IOMMU hardware. Patches are available across multiple kernel stable branches (6.6.128, 6.12.75, 6.18.16, 6.19.6, 7.0). EPSS score is low (0.02%, 5th percentile) with no confirmed active exploitation or public POC identified at time of analysis.
Use-after-free in Linux kernel AMD GPU driver allows local authenticated users to potentially execute arbitrary code, escalate privileges, or cause denial of service. The amdgpu_amdkfd_submit_ib() function in the AMD KFD (Kernel Fusion Driver) prematurely releases a DMA fence reference before waiting on it, creating a race condition where the fence memory may be freed before use. Vendor-released patches are available for multiple stable kernel branches (6.1.168, 6.6.131, 6.12.80, 6.18.21, 6.19.11, 7.0). EPSS exploitation probability is very low at 0.02% (7th percentile), and no public exploit or active exploitation has been identified at time of analysis.
Use-after-free in Linux kernel AMD display driver allows local authenticated users to execute arbitrary code, corrupt memory, or cause denial of service. Affects systems with AMD graphics using Display Stream Compression (DSC) and multi-stream transport (MST), particularly laptops with integrated displays and external DP-MST monitors. The vulnerability arises when mode changes occur simultaneously with DSC reconfigurations, causing improper stream lifecycle management. Vendor patch available across multiple kernel versions (6.12.80, 6.18.21, 6.19.11, 7.0). EPSS score of 0.02% indicates low exploitation probability in the wild, with no CISA KEV listing or public exploit identified at time of analysis.
The Handlebars npm package precompiler (bin/handlebars) allows arbitrary JavaScript injection through unsanitized string concatenation in four distinct code paths: template filenames, namespace option (-n), CommonJS path option (-c), and AMD path option (-h). Attackers who can control template filenames or CLI arguments can inject code that executes when the generated JavaScript bundle is loaded in Node.js or browser environments. Publicly available exploit code exists with multiple proof-of-concept vectors demonstrated, including file system manipulation via require('fs'). CVSS 8.3 reflects local attack vector requiring low privileges and user interaction, with changed scope allowing high confidentiality, integrity, and availability impact.
Attested TLS relay attacks in Cocos AI confidential computing system versions 0.4.0 through 0.8.2 enable attackers to impersonate genuine TEE-protected services on AMD SEV-SNP and Intel TDX platforms by extracting ephemeral TLS private keys and redirecting authenticated sessions. The architectural flaw allows an attacker with physical access or side-channel capabilities to relay attestation evidence to a different endpoint, breaking the authentication binding between the TEE and the client. No vendor-released patch is available; the vulnerability affects a specialized confidential computing platform with low EPSS probability (formal EPSS score not provided in input) and no public exploit identified at time of analysis, though formal ProVerif verification confirms the attack feasibility.
In the Linux kernel, the following vulnerability has been resolved: KVM: Don't clobber irqfd routing type when deassigning irqfd When deassigning a KVM_IRQFD, don't clobber the irqfd's copy of the IRQ's routing entry as doing so breaks kvm_arch_irq_bypass_del_producer() on x86 and arm64, which explicitly look for KVM_IRQ_ROUTING_MSI.
On BIG-IP versions 16.0.x before 16.0.1.1, 15.1.x before 15.1.2.1, 14.1.x before 14.1.4, 13.1.x before 13.1.3.6, and 12.1.x before 12.1.5.3 amd BIG-IQ 7.1.0.x before 7.1.0.3 and 7.0.0.x before. Rated critical severity (CVSS 9.8), this vulnerability is remotely exploitable, no authentication required, low attack complexity. Public exploit code available and no vendor patch available.
Boot-time arbitrary code execution is possible on AMD Versal Adaptive SoCs and related Alveo accelerator cards, but only when USB boot mode has been enabled through physical board modifications - a configuration AMD explicitly describes as non-default. A crafted boot image delivered over USB can trigger an out-of-bounds write (CWE-787) that overflows a buffer and overwrites an active function pointer, yielding high confidentiality, integrity, and availability impact confined to the boot process. Because exploitation requires both physical access to the device and a deliberately modified board, plus a non-trivial (high-complexity) overflow, realistic risk is limited to supply-chain, manufacturing, or evil-maid scenarios; no public exploit identified at time of analysis, and no confirmed in-the-wild activity, though the vendor bulletin AMD-SB-8028 documents the issue.
Denuvo Anti-Tamper (through 2026-03-04) can be bypassed by locally authenticated administrators with kernel-level privileges who load a hypervisor driver that intercepts CPUID instructions and spoofs hypervisor-absence results, defeating the anti-tamper check on AMD (SimpleSvm.sys) and Intel (hyperkd.sys, hyperhv.dll) platforms. The vulnerability has a CVSS score of 1.9 (AV:L/AC:H/PR:H) and only affects the integrity of the DRM check on the attacker's own system, with no third-party victim or escalation. No public exploit identified at time of analysis.
In the Linux kernel, the following vulnerability has been resolved: ASoC: amd: yc: fix memory leak in acp6x_pdm_dma_close() acp6x_pdm_dma_close() does not free the runtime->private_data buffer allocated in acp6x_pdm_dma_open(). Add the missing kfree.
In the Linux kernel, the following vulnerability has been resolved: iommu/amd: Do not reallocate GA log buffers on resume Commit c5e1a1eb9279 ("iommu/amd: Simplify and Consolidate Virtual APIC (AVIC) Enablement") moved the GA log allocation from iommu_init_pci() to enable_iommus_vapic(), which is called on every resume. iommu_init_ga_log() assigns iommu->ga_log and iommu->ga_log_tail unconditionally. Each resume therefore replaces the boot-time pointers and leaks both old allocations. The function also uses GFP_KERNEL from a syscore resume callback, where interrupts are disabled and the non-boot CPUs are offline. Return early if both buffers are already allocated. Clear the pointers in free_ga_log() so a partial allocation failure cannot leave ga_log dangling.
In the Linux kernel, the following vulnerability has been resolved: x86/amd_node: Fix potential NULL pointer dereference amd_smn_read/write() are exported functions around __amd_smn_rw(), so they are always available even if amd_smn_init() fails. In that case, 'amd_roots' is NULL and __amd_smn_rw() will access uninitialized memory. Then, commit: 83518453074d ("x86/amd_node: Add SMN offsets to exclusive region access") added the 'smn_exclusive' flag, which indicated the calls to pci_request_config_region_exclusive() succeeded, to prevent concurrent userspace access. Commit: 0a4b61d9c2e4 ("x86/amd_node: Fix AMD root device caching") re-ordered initialization so pci_request_config_region_exclusive() is called earlier and a failure exits amd_smn_init() before allocating 'amd_roots'. The setting of 'smn_exclusive' moved to the end of amd_smn_init(), after 'amd_roots' is allocated. It became redundant and can be removed. Replace 'smn_exclusive' with directly checking 'amd_roots', to fix a potential NULL pointer dereference and to simplify the logic. [ bp: Reorg commit message, touchup comment. ] [ mingo: Rebase & further touchups. ]
In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Avoid DPMS-on for phantom stream [Why & How] Calling dc_update_planes_and_stream separately for stream and its phantom stream causes a NULL pointer dereference, since the phantom is destroyed on the first call. Skip the call for phantom streams.
In the Linux kernel, the following vulnerability has been resolved: drm/amd/pm: bound pp_dpm_set_pp_table() memcpy The powerplay path allocates hardcode_pp_table once with kmemdup(..., soft_pp_table_size). memcpy(..., size) used the sysfs store count (up to PAGE_SIZE) with no upper bound, causing heap overflow. Reject writes where size exceeds soft_pp_table_size.
In the Linux kernel, the following vulnerability has been resolved: drm/amd/powerplay: fix VoltageObjectInfo zero-stride loop and OOB read Reject voltage objects whose usSize is smaller than the header or would advance the cursor past the table end, preventing an infinite loop or heap OOB read when the VBIOS supplies a malformed VoltageObjectInfo table.
In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Fix DM I2C teardown race DM I2C adapters can remain visible to userspace while DM teardown is already in progress. A concurrent i2c-dev transfer may then enter amdgpu_dm_i2c_xfer() after the backing DM state has been torn down, leading to a NULL pointer dereference. Create a devres group around the DM I2C adapter lifetime and release it at the start of dm_hw_fini(), before HPD, IRQ, and DM state are torn down. This removes the I2C adapters first and waits for in-flight users to drain before the structures used by amdgpu_dm_i2c_xfer() disappear. This fixes a teardown ordering race seen during device removal: BUG: kernel NULL pointer dereference RIP: amdgpu_dm_i2c_xfer+0x122/0x1c0 [amdgpu] Call Trace: __i2c_transfer i2c_transfer i2cdev_ioctl_rdwr
In the Linux kernel, the following vulnerability has been resolved: iommu/amd: Fix undefined behavior in devid_write debugfs function When for_each_pci_segment() loop completes without finding a matching segment, the pci_seg pointer is not NULL but points to an invalid memory location (the list head). Accessing pci_seg->id after the loop causes undefined behavior. Fix this by handling the successful case inside the loop and returning -EINVAL after the loop if no matching segment is found.
In the Linux kernel, the following vulnerability has been resolved: cpufreq: amd-pstate-ut: Skip tests when amd-pstate driver is not active The crash issue may occur when modprobe amd_pstate_ut on intel platform. amd_pstate_ut: 1 amd_pstate_ut_acpi_cpc_valid success! amd_pstate_ut: 2 amd_pstate_ut_check_enabled success! BUG: kernel NULL pointer dereference, address: 0000000000000080 #PF: supervisor read access in kernel mode #PF: error_code(0x0000) - not-present page PGD 0 P4D 0 Oops: 0000 [#1] SMP NOPTI CPU: 0 PID: 20300 Comm: modprobe Kdump: loaded Tainted: G O 6.6.0-0010.rc1.ctl4.x86_64 #1 Hardware name: FiberHome R2200 V5/Xeon Boards, BIOS 3.1a 02/24/2020 RIP: 0010:amd_pstate_ut_check_perf+0x141/0x280 [amd_pstate_ut] Call Trace: <TASK> amd_pstate_ut_init+0x1b/0xff0 [amd_pstate_ut] ? __pfx_amd_pstate_ut_init+0x10/0x10 [amd_pstate_ut] do_one_initcall+0x42/0x2e0 ? kmalloc_trace+0x26/0x90 do_init_module+0x60/0x240 __se_sys_init_module+0x185/0x1c0 do_syscall_64+0x62/0x190 entry_SYSCALL_64_after_hwframe+0x76/0x7e </TASK> Add state detection to amd pstate driver to prevent amd_pstate_ut driver from testing on non-AMD platforms. (ML: adjust title)
In the Linux kernel, the following vulnerability has been resolved: cpufreq/amd-pstate: handle missing policy in dynamic EPP callbacks cpufreq_cpu_get() returns NULL when no cpufreq policy is associated with the requested CPU, for example because the CPU is offline or the policy has already been torn down. Both amd_pstate_power_supply_notifier() and amd_pstate_profile_set() acquire a policy via cpufreq_cpu_get() and then pass that pointer to amd_pstate_get_balanced_epp() and amd_pstate_set_epp(), which dereference it unconditionally. A racing CPU hotplug or driver teardown can therefore lead to a NULL pointer dereference on either of these dynamic EPP paths. The third cpufreq_cpu_get() caller in this file, amd_pstate_verify(), already handles the NULL case. Bring the two new callers in line with that pattern: return NOTIFY_OK from the power-supply notifier (matching the other "nothing to do" exits) and -ENODEV from amd_pstate_profile_set() (the usual cpufreq error for a missing CPU policy). Found by code inspection; not tested on hardware.
In the Linux kernel, the following vulnerability has been resolved: i3c: dw: avoid shift-out-of-bounds when DAA assigns no devices On an empty bus ENTDAA assigns nothing, so cmd->rx_len (the count of addresses left unassigned) equals master->maxdevs. The GENMASK() index master->maxdevs - cmd->rx_len - 1 then becomes -1, which trips up UBSAN. This happens every time on boot on a Gigabyte/AMD server: UBSAN: shift-out-of-bounds in drivers/i3c/master/dw-i3c-master.c:905:12 shift exponent 64 is too large for 64-bit type 'long unsigned int' CPU: 7 UID: 0 PID: 963 Comm: (udev-worker) Not tainted 7.0.11-200.fc44.x86_64 #1 PREEMPT(lazy) Hardware name: Giga Computing E163-Z34-AAH1-000/MZ33-DC1-000, BIOS R32_F45 04/01/2026 Call Trace: <TASK> dump_stack_lvl+0x5d/0x80 ubsan_epilogue+0x5/0x2b __ubsan_handle_shift_out_of_bounds.cold+0xd7/0x1ab dw_i3c_master_daa.cold+0x1b/0x96 [dw_i3c_master] i3c_master_do_daa_ext.part.0+0x3e/0xf0 [i3c] Skip the mask when no new device was assigned.
In the Linux kernel, the following vulnerability has been resolved: media: amd: isp4: release partial allocations in isp4if_alloc_fw_gpumem() isp4if_alloc_fw_gpumem() allocates several GPU memory pools in sequence. If one of them fails, it jumps to error_no_memory and returns -ENOMEM without releasing the pools that were already allocated, leaking them. Release the already-allocated pools before returning. isp4if_gpu_mem_free() is a no-op on pools that were not allocated, so calling isp4if_dealloc_fw_gpumem() here safely frees exactly the pools that succeeded. isp4if_gpu_mem_free() previously logged an error for a NULL entry, which is a normal case during partial-allocation cleanup, so make it silent.
In the Linux kernel, the following vulnerability has been resolved: media: amd: isp4: fix self-deadlock in isp4sd_pwron_and_init() error path isp4sd_pwron_and_init() holds ops_mutex via guard(mutex) and, on any init failure, jumps to err_deinit and calls isp4sd_pwroff_and_deinit(). That helper takes the same ops_mutex, re-acquiring a non-recursive mutex already held by the current thread, so any init failure deadlocks. Unwind the error path in stages instead, releasing only what each failure point acquired. This also avoids the issues that an unconditional teardown would hit at the earlier failures, such as a runtime-PM underflow from pm_runtime_resume_and_get() and MMIO access while the device is unpowered.
In the Linux kernel, the following vulnerability has been resolved: platform/x86/amd/hsmp: Reject negative power cap writes in hwmon hsmp_hwmon_write() takes the user-supplied hwmon value as a signed long and assigns "val / MICROWATT_PER_MILLIWATT" to msg.args[0], which is a __u32. MICROWATT_PER_MILLIWATT is an unsigned long, so a negative write to power1_cap (e.g. "echo -1 > power1_cap") is first converted to a huge unsigned value by the division and then stored into the u32 argument. As a result a nonsensical, multi-gigawatt socket power limit is sent to the SMU via HSMP_SET_SOCKET_POWER_LIMIT instead of the write being rejected. Reject negative values with -EINVAL before the conversion. Tested with HSMP enabled: CAP=$(dirname $(grep -l amd_hsmp_hwmon \ /sys/class/hwmon/hwmon*/name | head -1))/power1_cap # negative write echo -1000000 > $CAP ; echo "ret=$?" # valid positive write must still work echo 400000000 > $CAP ; echo "ret=$?" Before: # echo -1000000 > $CAP ; echo "ret=$?" ret=0 <- accepted; bogus limit sent to SMU # echo 400000000 > $CAP ; echo "ret=$?" ret=0 After: # echo -1000000 > $CAP ; echo "ret=$?" bash: echo: write error: Invalid argument ret=1 <- rejected with -EINVAL # echo 400000000 > $CAP ; echo "ret=$?" ret=0 <- valid write still works
In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: fix division by zero in get_estimated_bw() get_estimated_bw() divides by link->dpia_bw_alloc_config.bw_granularity, which is zeroed by reset_bw_alloc_struct() and only populated once DP_TUNNELING_BW_ALLOC_CAP_CHANGED has been handled. link_dp_dpia_handle_bw_alloc_status(), the DPCD interrupt handler, calls get_estimated_bw() whenever DP_TUNNELING_ESTIMATED_BW_CHANGED is set, independently of whether DP_TUNNELING_BW_ALLOC_CAP_CHANGED has ever fired for that link. A connected USB4/DPIA tunneling device that reports an estimated-bandwidth change before ever reporting a capability change drives a division by zero in this IRQ path. link_dpia_send_bw_alloc_request() already guards the same bw_granularity division; add the identical guard here rather than introducing a new pattern. (cherry picked from commit f2a961457c33dc34223aad5c9e8971de34a4eed3)
In the Linux kernel, the following vulnerability has been resolved: dma-buf: dma-heap: don't publish fd before copy_to_user() succeeds DMA_HEAP_IOCTL_ALLOC allocates a dma-buf and installs an fd into the caller's fd table via dma_buf_fd() -> fd_install() before dma_heap_ioctl() copies the result back to userspace. If the trailing copy_to_user() fails, userspace never learns the fd number, but the fd (and the underlying dma-buf reference) are already visible to other threads in the same process and are leaked for the lifetime of the process. The obvious "close it on the failure path" fix is unsafe: once fd_install() has run, another thread can already dup() the fd, send it via SCM_RIGHTS, or close() it and let its number be reused, so a subsequent close_fd() from the ioctl path can operate on an unrelated file. This was pointed out by Christian König on v1 [1]. Restructure the allocation path so that fd_install() is the last, unfailable step of a successful ioctl: 1. heap->ops->allocate() creates the dma_buf. 2. get_unused_fd_flags() reserves an fd number in the caller's fd table without publishing it, so no other thread can observe it. 3. copy_to_user() delivers the fd number to userspace; on failure the fd is returned with put_unused_fd() and the dma_buf reference is dropped with dma_buf_put(), leaving no user- visible state behind. 4. dma_buf_fd_install() publishes the fd and emits the trace_dma_buf_fd tracepoint -- from here on the ioctl cannot fail. A new dma_buf_fd_install() helper is introduced in dma-buf.c to wrap fd_install() together with the DMA_BUF_TRACE() call, preserving the export tracing that dma_buf_fd() provides. dma_heap_ioctl_allocate() is refactored to return the struct dma_buf * directly (returning ERR_PTR on failure) so the caller holds the dmabuf reference across steps 3 and 4. The failure at step 3 is easily reachable from userspace: pass a struct dma_heap_allocation_data that lives in a page whose protection is flipped to PROT_READ between copy_from_user() and copy_to_user() (e.g. via mprotect()). Before this change each such ioctl leaks one dmabuf fd; after it, the fd table is unchanged on failure and only /dev/dma_heap/<name> remains open. No UAPI or heap-driver interface change. [1] https://lore.kernel.org/dri-devel/175e98de-f414-47d7-81c1-c0fe0a8f7f62@amd.com/
In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: avoid divide-by-zero in __is_lut_linear() __is_lut_linear() computes the expected value of each entry with expected = i * MAX_DRM_LUT_VALUE / (size - 1); If it is ever called with a single-entry LUT, size - 1 is zero and the kernel takes a divide error (#DE). A LUT with fewer than two entries cannot describe a linear mapping anyway, so return false early instead of dividing by zero.
In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: fix dc_lock leak on GPU reset error paths On GPU reset, dm_suspend() takes dc_lock and leaves it for dm_resume() to drop. If amdgpu_dm_commit_zero_streams() or dm_dmub_hw_init() fails, the function returns with the lock still held. The matching resume path is then skipped, so every later dc_lock take hangs. Release the cached DC state and unlock before returning the error.
In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Skip Update HDCP Config In Transition State Transition state does not have a valid dm_stream_ctx that should skip configuring HDCP routine. The routine is valid to go through only when a valid stream is created.
In the Linux kernel, the following vulnerability has been resolved: iommu/amd: Put PCI device after handling PPR faults iommu_call_iopf_notifier() looks up the requester with pci_get_domain_bus_and_slot(), which returns a PCI device with its reference count incremented. Neither the successful iommu_report_device_fault() path nor the abort path drops that reference, so every handled PPR request leaks a PCI device reference. This is the same ownership rule that was fixed for the old iommu_v2 ppr_notifier() path by commit 6cf0981c2233 ("iommu/amd: Fix pci device refcount leak in ppr_notifier()"), but iommu_call_iopf_notifier() was added later as a separate PPR/IOPF notifier path. Drop the PCI device reference after handling the PPR entry.
In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: check if dml21_add_phantom_plane() is successful Verify that the phantom plane was allocated to avoid a later segfault. (cherry picked from commit 5adb54abe5a8e82cbff7f8806db30a5f4924329f)
In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: use proper context for logging The same as the rest of the code, get_ss_info_from_atombios() uses calc_pll_cs->ctx->logger for logging. But calc_pll_cs->ctx is initialized only later in calc_pll_max_vco_construct(). Therefore, any output using DC_LOG_SYNC() leads to a NULL pointer deference in get_ss_info_from_atombios(). According to Sashiko, the very same problem exists in dce112_get_pix_clk_dividers() and dcn3_get_pix_clk_dividers() too. To avoid accessing the NULL context, use clk_src->base.ctx->logger everywhere. That context in base is initialized earlier in dce110_clk_src_construct() and dce112_clk_src_construct(). Before get_ss_info_from_atombios() or Sashiko's get_pix_clk_dividers functions above are actually called. This is done by redefining DC_LOGGER to CTX->logger. Before: dce110_clk_src_construct() did: -> sets clk_src->base.ctx = ctx; -> ss_info_from_atombios_create() -> get_ss_info_from_atombios() <- uses calc_pll_cs->ctx # BOOM -> calc_pll_max_vco_construct() <- sets calc_pll_cs->ctx After: dce110_clk_src_construct() does: -> sets clk_src->base.ctx = ctx; -> ss_info_from_atombios_create() -> get_ss_info_from_atombios() <- uses clk_src->base.ctx (cherry picked from commit 6f16fcbb0c46a87e3d9685407e906573d60104b0)
In the Linux kernel, the following vulnerability has been resolved: perf/x86/amd/lbr: Fix kernel address leakage A user-only branch stack can contain branches that originate from the kernel. As a result, kernel addresses are exposed to user space even when PERF_SAMPLE_BRANCH_USER is requested. On AMD processors supporting X86_FEATURE_AMD_LBR_V2, perf can still report SYSRET/ERET entries for which the branch-from addresses are in the kernel. E.g. $ perf record -e cycles -o - -j any,save_type,u -- \ perf bench syscall basic --loop 1000 | \ perf script -i - -F brstack|tr ' ' '\n'| \ grep -E '0x[89a-f][0-9a-f]{15}' ... 0xffffffff81001268/0x717a90a38f1a/M/-/-/0/ERET/NON_SPEC_CORRECT_PATH 0xffffffff81001268/0x717a90a39157/M/-/-/0/ERET/NON_SPEC_CORRECT_PATH 0xffffffff81001268/0x717a90a2c628/M/-/-/0/ERET/NON_SPEC_CORRECT_PATH 0xffffffff81001268/0x717a90a41b60/M/-/-/0/ERET/NON_SPEC_CORRECT_PATH 0xffffffff81001268/0x717a90a260db/M/-/-/0/ERET/NON_SPEC_CORRECT_PATH 0xffffffff81001268/0x717a90a260db/M/-/-/0/ERET/NON_SPEC_CORRECT_PATH 0xffffffff81001268/0x717a8bef1c30/M/-/-/0/ERET/NON_SPEC_CORRECT_PATH 0xffffffff81001268/0x717a8e4d3c90/M/-/-/0/ERET/NON_SPEC_CORRECT_PATH ... The reason is that the hardware filter only considers the privilege level applicable to the branch target. Extend software filtering to also validate the branch-from addresses against br_sel, so that any branch record whose branch-from address is in the kernel is dropped when PERF_SAMPLE_BRANCH_USER is requested.
In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Fix NULL pointer dereference in amdgpu_dm_crtc_set_vblank() amdgpu_dm_crtc_set_vblank() dereferences acrtc_state->stream when vblank is enabled/queried from DRM_IOCTL_MODE_CRTC_GET_SEQUENCE before a stream is attached to it. BUG: kernel NULL pointer dereference, address: 0000000000000008 RIP: amdgpu_dm_crtc_set_vblank+0x6b/0x4d0 [amdgpu] Call Trace: drm_vblank_enable drm_vblank_get drm_crtc_get_sequence_ioctl drm_ioctl_kernel drm_ioctl Reproduced by running VKCTS with WSI tests enabled on RADV. Guard the enable path on acrtc_state->stream being non-NULL, matching the existing checks in this function. (cherry picked from commit 7b1b31bf6942e6f43509b48da23f8e27269aac39)
In the Linux kernel, the following vulnerability has been resolved: perf/x86/amd/brs: Fix kernel address leakage A user-only branch stack can contain branches that originate from the kernel. As a result, kernel addresses are exposed to user space even when PERF_SAMPLE_BRANCH_USER is requested. On AMD processors supporting X86_FEATURE_BRS (Zen 3 only), perf can still report entries such as SYSRET/interrupt returns for which the branch-from addresses are in the kernel. E.g. $ perf record -j any,u -c 4000 -e branch-brs -o - -- \ perf bench syscall basic --loop 1000 | \ perf script -i - -F brstack|tr ' ' '\n'| \ grep -E '0x[89a-f][0-9a-f]{15}' ... 0xffffffff810001c4/0x72e2e32955eb/-/-/-/0//- 0xffffffff810001c4/0x72e2d94a9821/-/-/-/0//- 0xffffffff810001c4/0x72e2d94ffa1b/-/-/-/0//- ... BRS provides no hardware branch filtering, so privilege level filtering is performed entirely in software. However, amd_brs_match_plm() only validates the branch-to address against the requested privilege levels. For branches from the kernel to user space, the branch-from address is left unchecked and is leaked. Extend the software filter to also validate the branch-from address, so that any branch record whose branch-from address is in the kernel is dropped when PERF_SAMPLE_BRANCH_USER is requested.
In the Linux kernel, the following vulnerability has been resolved: accel/amdxdna: reject user command submission without a command BO amdxdna_drm_submit_execbuf() passes the user-supplied command BO handle straight into amdxdna_cmd_submit() with drv_cmd == NULL. When the handle is AMDXDNA_INVALID_BO_HANDLE (0), the block that fetches job->cmd_bo is skipped, leaving it NULL, and no check rejects it on the user path (the !job->cmd_bo guard lives inside the != INVALID branch). The job is then armed and pushed to the DRM scheduler. aie2_sched_job_run() takes the drv_cmd == NULL path and calls amdxdna_cmd_set_state(job->cmd_bo) -> amdxdna_gem_vmap(NULL) -> to_gobj(NULL)->dev, a NULL pointer dereference in the drm_sched worker. A process with access to the accel node on a system with a probed AMD NPU can trigger a kernel oops with a single AMDXDNA_EXEC_CMD ioctl (cmd_handles = 0). Only internal driver commands (SYNC_DEBUG_BO / ATTACH_DEBUG_BO) legitimately pass AMDXDNA_INVALID_BO_HANDLE, and they always set drv_cmd. Reject the invalid handle for user submissions (drv_cmd == NULL) at the submit choke point so every user path is covered. Found by 0sec automated security-research tooling (https://0sec.ai).
In the Linux kernel, the following vulnerability has been resolved: perf/x86/amd/core: Avoid enabling BRS from the SVM reload path Branch Sampling (BRS) and Last Branch Record (LBR) are mutually exclusive hardware features, and users of both are tracked via cpuc->lbr_users. When SVM is toggled on a CPU, the host perf events are reprogrammed to update the HostOnly filter bit (set when virtualization is enabled, cleared when it is disabled). On PerfMonV2-capable processors, this reprogramming is performed by calling amd_pmu_enable_all() to rewrite the event selectors. However, amd_pmu_enable_all() also calls amd_brs_enable_all(), which enables BRS whenever cpuc->lbr_users > 0. Having active LBR events satisfies this gating on processors that have LBR but not BRS. The kernel then tries to set the BRS enable bit in DebugExtnCfg (MSR 0xc000010f). Since that bit is deprecated on such hardware, the write results in a #GP: Call Trace: <IRQ> amd_pmu_enable_all+0x1d/0x90 amd_pmu_disable_virt+0x62/0xb0 kvm_arch_disable_virtualization_cpu+0xa/0x40 [kvm] hardware_disable_nolock+0x1a/0x30 [kvm] __flush_smp_call_function_queue+0x9b/0x410 __sysvec_call_function+0x18/0xc0 sysvec_call_function+0x69/0x90 </IRQ> <TASK> asm_sysvec_call_function+0x16/0x20 RIP: 0010:cpuidle_enter_state+0xc4/0x450 ? cpuidle_enter_state+0xb7/0x450 cpuidle_enter+0x29/0x40 cpuidle_idle_call+0xf5/0x160 do_idle+0x7b/0xe0 cpu_startup_entry+0x26/0x30 start_secondary+0x115/0x140 secondary_startup_64_no_verify+0x194/0x19b </TASK> Fix this by ensuring that BRS is not enabled from the event selector reprogramming path even when cpuc->lbr_users > 0.
Use-After-Free in the AMD Ryzen Master Utility Driver exposes kernel memory to a locally authenticated, high-privileged attacker, with the primary confirmed impact being system availability loss. The vulnerability (CWE-416) resides within the driver component bundled with both the Ryzen Master application and its Monitoring SDK, affecting all versions prior to the patched releases. No public exploit code or active exploitation has been identified at time of analysis, and the CVSS 4.0 score of 5.6 reflects the restricted local, high-privilege attack surface despite the kernel-level nature of the flaw.
DLL hijacking during the AMD Ryzen Master installation process allows a local low-privileged attacker to escalate privileges and execute arbitrary code on Windows systems running affected versions. The flaw, rooted in an uncontrolled DLL search path (CWE-427), affects AMD Ryzen Master up to 3.0.0.4199, Ryzen Master SDK up to 3.0.1.4732, and a legacy branch for Ryzen 3000 Series processors up to 2.14.3.5040. No public exploit code has been identified at time of analysis, and this vulnerability is not listed in the CISA KEV catalog.
Information disclosure in AMD Zen processor microarchitecture, surfaced through Windows system software, enables a local low-privileged attacker to read high-sensitivity data across security boundaries. The CVSS Scope Changed metric (S:C) combined with C:H and the AMD Zen tag strongly suggests a microarchitectural side-channel capable of leaking data from outside the attacker's security context - a pattern consistent with speculative execution or cache-based cross-boundary leakage. No public exploit has been identified at time of analysis, and CISA SSVC rates exploitation status as none; however, the breadth of affected Windows versions (Server 2012 R2 through Server 2025 and Windows 10/11 across all supported channels) gives this a wide potential exposure surface on AMD Zen-equipped systems.
Information disclosure in AMD Zen processors on Windows allows a locally authenticated low-privileged attacker to read sensitive memory contents across security boundaries via a high-complexity microarchitectural technique. Affecting Windows versions from Windows 10 1607 to Windows 11 26H1 and Server 2012 R2 through Server 2025, this vulnerability was reported by Microsoft's security team (secure@microsoft.com) and carries a CVSS 5.6 medium score with Scope:Changed (S:C) indicating the attacker can cross a privilege boundary to reach data outside their own security context. No public exploit code exists and the vulnerability is absent from the CISA KEV catalog, though vendor-released patches are confirmed available via MSRC.
DLL hijacking in AMD Power Design Manager (PDM) enables a local, low-privileged attacker to escalate privileges during the software's uninstallation process, ultimately achieving arbitrary code execution at a higher privilege level. The vulnerability stems from CWE-427 (Uncontrolled Search Path Element), where the PDM uninstaller resolves DLL dependencies from directories writable by unprivileged users. AMD PSIRT confirmed the issue and released an Un-Installer patch at version 2026.1 via Security Bulletin AMD-SB-8016; no public exploit code or CISA KEV listing has been identified at time of analysis.
In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Fix ISM dc_lock deadlock during suspend [Why] System hang observed during suspend/resume while video is playing. amdgpu_dm_ism_disable() is called under dc_lock and waits for ISM delayed work via disable_delayed_work_sync(). The work handlers themselves take dc_lock, producing an ABBA deadlock when a worker is in flight at suspend time. [How] Split the disable path into two phases with opposite locking contracts: 1. amdgpu_dm_ism_disable() -- quiesces workers, must NOT hold dc_lock. 2. amdgpu_dm_ism_force_full_power() (new) -- drives the ISM FSM back to FULL_POWER_RUNNING, must hold dc_lock.
In the Linux kernel, the following vulnerability has been resolved: iommu/amd: Fix IRQ unsafe locking in gdom allocation Lockdep complains: [ 259.410489] ===================================================== [ 259.417287] WARNING: HARDIRQ-safe -> HARDIRQ-unsafe lock order detected [ 259.424667] 7.0.0-g51db1d8d2113 #54 Not tainted [ 259.429718] ----------------------------------------------------- [ 259.436516] qemu-system-x86/10143 [HC0[0]:SC0[0]:HE0:SE1] is trying to acquire: [ 259.444670] ff3b2b1c60305170 (&xa->xa_lock#25){+.+.}-{3:3}, at: __domain_flush_pages+0x17c/0x4b0 [ 259.454485] and this task is already holding: [ 259.460991] ff3b2b1c98504cc0 (&domain->lock){-.-.}-{3:3}, at: amd_iommu_iotlb_sync+0x25/0x60 [ 259.470408] which would create a new lock dependency: [ 259.476041] (&domain->lock){-.-.}-{3:3} -> (&xa->xa_lock#25){+.+.}-{3:3} [ 259.483615] but this new dependency connects a HARDIRQ-irq-safe lock: [ 259.492447] (&domain->lock){-.-.}-{3:3} [ 259.492449] ... which became HARDIRQ-irq-safe at: [ 259.503705] lock_acquire+0xb6/0x2e0 [ 259.507790] _raw_spin_lock_irqsave+0x3e/0x60 [ 259.512748] amd_iommu_flush_iotlb_all+0x20/0x50 [ 259.517996] iommu_dma_free_iova.isra.0+0x1b8/0x1e0 [ 259.523534] __iommu_dma_unmap+0xc2/0x140 [ 259.528100] iommu_dma_unmap_phys+0x55/0xc0 [ 259.532863] dma_unmap_phys+0x274/0x2e0 [ 259.537238] dma_unmap_page_attrs+0x17/0x30 [ 259.542000] nvme_unmap_data+0x13e/0x280 [ 259.546473] nvme_pci_complete_batch+0x45/0x70 [ 259.551524] nvme_irq+0x83/0x90 [ 259.555123] __handle_irq_event_percpu+0x92/0x360 [ 259.560466] handle_irq_event+0x39/0x80 [ 259.564841] handle_edge_irq+0xb2/0x1a0 [ 259.569214] __common_interrupt+0x4e/0x130 [ 259.573882] common_interrupt+0x88/0xa0 [ 259.578256] asm_common_interrupt+0x27/0x40 [ 259.583019] cpuidle_enter_state+0x119/0x5d0 [ 259.587877] cpuidle_enter+0x2e/0x50 [ 259.591962] do_idle+0x153/0x2c0 [ 259.595657] cpu_startup_entry+0x29/0x30 [ 259.600128] start_secondary+0x118/0x150 [ 259.604601] common_startup_64+0x13e/0x141 [ 259.609266] to a HARDIRQ-irq-unsafe lock: [ 259.615384] (&xa->xa_lock#25){+.+.}-{3:3} [ 259.615386] ... which became HARDIRQ-irq-unsafe at: [ 259.627039] ... [ 259.627039] lock_acquire+0xb6/0x2e0 [ 259.633071] _raw_spin_lock+0x2f/0x50 [ 259.637250] amd_iommu_alloc_domain_nested+0x140/0x3c0 [ 259.643078] iommufd_hwpt_alloc+0x272/0x800 [iommufd] [ 259.648813] iommufd_fops_ioctl+0x14e/0x200 [iommufd] [ 259.654547] __x64_sys_ioctl+0x9d/0xf0 ... Since amd_iommu_domain_flush_pages() necessarily holds domain->lock to do the flush, switch the allocation side in gdom_info_load_or_alloc_locked() to HARDIRQ-safe allocation. The IOMMU_DESTROY->free path has the same issue, so switch that path to HARDIRQ-safe locking as well.
In the Linux kernel, the following vulnerability has been resolved: iommu/amd: Bound the early ACPI HID map The ivrs_acpihid command-line parser appends entries to a fixed four-element early_acpihid_map array. Unlike the sibling IOAPIC and HPET parsers, it does not reject a fifth entry before incrementing the map size. Check the capacity at the common found label before parsing the HID and UID or writing the entry.
In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: detect_link_and_local_sink: DP alt mode timeout path leaks prev_sink reference prev_sink is unconditionally retained via dc_sink_retain at function entry, but the DP alt mode timeout path inside SIGNAL_TYPE_DISPLAY_PORT returns false without releasing prev_sink. All other return paths in the function correctly call dc_sink_release(prev_sink), making this the only missing cleanup. (cherry picked from commit 45510cf662dcf46b5d8926d454f338809f107b9d)
In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: dce100: skip non-DP stream encoders for DP MST On DCE8-class ASICs (e.g. Bonaire), the resource pool contains digital DIG stream encoders plus one analog DAC encoder. When assigning a stream encoder for a second DisplayPort MST stream, if the preferred digital encoder is already acquired, dce100_find_first_free_match_stream_enc_for_link() falls back to the first free pool entry. That entry may be the analog encoder, whose funcs table lacks DP hooks such as dp_set_stream_attribute. The subsequent atomic commit then dereferences NULL function pointers in link_set_dpms_on() and crashes. Skip encoders without dp_set_stream_attribute when the stream uses a DP signal (including MST). Use dc_is_dp_signal(stream->signal) for the MST fallback path instead of checking only the link connector signal. Tested on: - GPU: AMD Radeon R7 260X (Bonaire / DCE8) - Board: Supermicro C9X299-PG300 - Setup: DP MST daisy chain, hotplug second monitor or have it connected on boot - Kernel: 7.1.3 (issue observed since 6.19) - Result: kernel oops without patch; dual monitors stable with patch (cherry picked from commit 28ec64943e3ee4d9b8d30cea61e380f1429953a8)
Broadcast TLB flush in the Linux kernel x86 memory management subsystem triggers a General Protection Fault (#GP) on AMD INVLPGB-capable systems booted with the 'nopcid' parameter, causing a kernel panic and local denial of service. When PCID is disabled via 'nopcid', CR4.PCIDE is not set, but the INVLPGB broadcast TLB invalidation path remains enabled; once a memory descriptor becomes active across more than three CPUs, the kernel assigns it a global ASID and issues INVLPGB with a non-zero PCID - an illegal state that crashes the kernel. No public exploit exists, EPSS is 0.17% (6th percentile), and this is not in CISA KEV; real-world impact is constrained to the uncommon 'nopcid' boot configuration on AMD hardware.
Attacker-controlled pointer dereference in AMD's ROCm Communication Collectives Library (RCCL) can escalate to remote code execution when a compromised peer rank - or a network-adjacent attacker on the collective fabric - participates in a multi-GPU or multi-node distributed workload. The defect (CWE-822, untrusted pointer dereference) affects RCCL running on AMD Instinct MI200/MI300/MI350-class accelerators and carries a CVSS 4.0 base score of 7.7 (vector AV:N/AC:H/AT:N/PR:L/UI:N, High confidentiality/integrity/availability), mapping to an assessed CVSS 3.1 of AV:N/AC:H/PR:L/UI:N/S:U/C:H/I:H/A:H. Exploitation is not confirmed as active (CVE is not in CISA KEV) and no public exploit code has been identified at time of analysis; the attack requires a pre-existing foothold as a peer rank inside the collective group rather than anonymous internet access, so this is a moderate-priority issue for distributed AMD GPU deployments rather than an internet-wide emergency.
Use-after-free in the Linux kernel's drm/ttm graphics memory manager (a regression introduced by commit b2ed01e7ad3d, present in roughly 7.0.10 through 7.1 and in stable backports such as Ubuntu 7.0.0-31) allows a locally authenticated user with an active GPU workload to crash the kernel minutes to hours after a swapout event. Because ttm_bo_swapout_cb() skips the bulk_move bookkeeping on successful swapout, a swapped-out resource stays on its buffer object's bulk_move range and on the manager LRU while being unevictable; when it is later freed or the BO leaves the bulk_move, ttm_resource_del_bulk_move() skips it due to its unevictable guard, leaving a dangling cursor that the next ttm_lru_bulk_move_tail() or ttm_resource_add_bulk_move() dereferences. Exploitation requires local presence, an affected AMD/drm-ttm system, and timing-dependent hibernation or memory-pressure conditions (the reporter observed crashes in only 5 of 18 hibernation cycles), and no public exploit code has been identified at time of analysis; EPSS is 0.20% (9th percentile), signalling low near-term exploitation likelihood.
Unauthorized code execution during the boot process is possible on AMD Zynq UltraScale+ MPSoC, Zynq UltraScale+ RFSoC, and Kria SOM devices when an attacker with physical or local USB access can drive oversized Device Firmware Upgrade (DFU) download requests while the device is held in USB boot mode. The flaw is an out-of-bounds write (CWE-787) in the USB boot-mode DFU path: missing boundary validation allows the download to overflow the DDR receive buffer and corrupt adjacent First Stage Boot Loader (FSBL) memory before the FSBL hands off to later boot stages. AMD rates this 7.5 (CVSS 4.0 AV:L/AC:L/AT:P/PR:N/UI:N with High confidentiality, integrity, and availability impact to the device); no public exploit code and no confirmed active exploitation were identified at time of analysis, and practical exposure is limited to devices whose boot configuration actually permits USB boot rather than QSPI/eMMC/SD.
Host-controlled AML injection in Edgeless Systems' Contrast confidential-computing runtime before 1.18.0 lets an adversary who controls the QEMU host achieve arbitrary code execution inside AMD SEV-SNP guest VMs, including reads and writes to private memory pages that the confidential-computing model is supposed to shield. Only the Metal-QEMU-SNP and Metal-QEMU-SNP-GPU platforms are affected; Metal-QEMU-TDX is not, because OVMF measures ACPI table contents into RTMR 0 on Intel TDX. The flaw is rated CVSS 8.4 (CVSS:4.0/AV:L/AC:L/AT:N/PR:L/UI:N/VC:H/VI:H/VA:N) via the host-to-guest trust boundary, carries no CISA KEV status and no public exploit code identified at time of analysis, and is fixed in Contrast 1.18.0, which sandboxes the kernel AML interpreter; the underlying BadAML technique is publicly documented in academic and Black Hat EU 2024 research, and the weakness is generic to Confidential Computing deployments that expose the ACPI interface to the host.
A kernel error-handling bug in the AMD IOMMU nested-domain allocation path of the Linux kernel (7.x, AMD-Vi/vIOMMU systems) causes domain-ID allocation failures to be silently ignored, so a nested IOMMU domain can be set up using a host domain ID that was never actually allocated. The flaw is reachable only by a locally privileged caller able to create IOMMU domains (iommufd/vIOMMU nested translation) and only when amd_iommu_pdom_id_alloc() actually fails (domain-ID space exhaustion or short memory), so it is a real but difficult-to-trigger error-path defect with no public exploit identified at time of analysis. Notably, the 7.8 NVD-style score (S:C/C:H/I:H/A:H) is inconsistent with the practical impact, which the independent assessment rates as limited integrity and availability gain on the error path only; vendor patches are available.
Page-table corruption can be triggered on LoongArch Linux kernels when the architecture fails to define DIRECT_MAP_PHYSMEM_END, causing get_free_mem_region() and mhp_get_pluggable_range() to fall back to the generic mm.h constant (1ULL << MAX_PHYSMEM_BITS) - 1 instead of the CPU's actual vmemmap-covered range. On LoongArch CPUs whose probed physical address bits (cpu_pabits from CPUCFG1) are fewer than MAX_PHYSMEM_BITS - notably the Loongson-2K series - a ZONE_DEVICE region can be allocated outside the vmemmap window, and vmemmap_populate() then wraps the memmap range around into low memory, silently corrupting page tables. The bug is local (CVSS vector PR:L), requires specific hardware plus CONFIG_SPARSEMEM_VMEMMAP and the ZONE_DEVICE/device-memory or amdkfd code path, and our independent assessment rates it AC:H with only C:L (versus the auto-generated 7.8 score with AC:L/C:H); no public exploit code or CISA KEV entry was identified at time of analysis.
An attestation-freshness and origin-validation failure in the aTLS AMD SEV-SNP verification path of Cocos AI (Ultraviolet) affects versions up to and including 0.8.2: when a relying party invokes the intra-handshake verification path with no expected reportData value (nil, empty, or omitted), the SEV-SNP policy ReportData is left unset and the verifier will accept unrelated or stale Evidence that is not bound to the current TLS connection. An attacker who possesses a valid but foreign or replayed SEV-SNP attestation blob can therefore induce a trusting party to accept an unintended attestation context, undermining the core trust guarantee of the confidential-computing platform and potentially enabling both integrity and confidentiality compromise in any workflow where aTLS output drives a trust or authorization decision. Exploitation is unauthenticated at the network layer (CVSS PR:N) but constrained by high attack complexity and specific prerequisites - the caller must omit the expected reportData, and only SEV-SNP aTLS deployments up to 0.8.2 are exposed; no public exploit code or confirmed active exploitation has been identified at time of analysis. The issue is fixed in version 0.9.0.
A dangling pointer in the Linux kernel's AMD display (amdgpu/DC) plane-reset path allows a locally logged-in, low-privileged user to leave a freed plane-state object referenced, which can crash the kernel. The bug lives in amdgpu_dm_plane_drm_plane_reset(), which freed the old state before allocating its replacement and, when that kzalloc() failed, returned without updating the pointer, so the failure path left a stale reference to released memory. Affected systems are those with an AMD GPU running the amdgpu display core code (Linux 6.0 onward per EUVD data); exploitation is constrained because the dangling pointer only materialises under a precisely timed kernel memory-allocation failure that an attacker cannot reliably force, giving an assessed availability-only impact (CVSS:3.1/AV:L/AC:H/PR:L/UI:N/S:U/C:N/I:N/A:H) rather than code execution. No public exploit code was identified at time of analysis and there is no CISA KEV confirmation; vendor patches are available via the upstream stable commits listed in the references.
A dangling-pointer condition in the AMD display (amdgpu) driver of the Linux kernel can leave a CRTC state pointer referencing freed memory when amdgpu_dm_crtc_reset_state() runs: the function frees the old state before attempting kzalloc() for the replacement, and if that allocation fails it returns without updating the pointer. Systems running AMD GPUs are affected, tracing back to kernel 4.15-era code, with fixes shipped in Linux 7.2.6 and 7.3-rc1. Triggering this requires local access to the amdgpu DRM device plus a carefully timed allocation failure (memory exhaustion), so while the vendor-scored severity is 7.8, the assessed impact is limited to a possible kernel crash (availability only) for a local user with existing device access; no public exploit code has been identified at time of analysis and there is no confirmed active exploitation (not in CISA KEV).
An off-by-one array-sizing bug in the Linux kernel's AMD display driver (drm/amd/display) lets a local low-privileged user trigger an out-of-bounds access to the per-connector MST HDCP arrays when a Multi-Stream Transport topology presents the 32nd connector that DRM core supports; the constant AMDGPU_DM_MAX_DISPLAY_INDEX was 31 but used as a connector count/size, leaving the arrays one element short. Per the independent assessment (CVSS:3.1/AV:L/AC:H/PR:L/UI:N/S:U/C:L/I:L/A:H), exploitation requires an AMD GPU running amdgpu with HDCP over MST and an MST hub/daisy-chain exposing the full 32 connectors, so it is limited by a physical topology precondition and by being a bounded single-element overrun rather than an attacker-sized overflow - systems with one to three displays never reach the vulnerable index. A vendor patch is available (Linux 7.2.6 and 7.3-rc1 stable releases, plus the corresponding upstream commits); no public exploit code exists and no active exploitation has been confirmed (not in CISA KEV).
Missing validation of the plane degamma LUT size in the Linux kernel's AMD display driver (amdgpu/DC) lets a local, authenticated user who can submit DRM atomic commits supply a malformed AMD_PLANE_DEGAMMA_LUT blob - for example a single-entry LUT - and drive the kernel into a divide-by-zero in __is_lut_linear() or an out-of-bounds read in __drm_lut_to_dc_gamma(). The practical consequence is a kernel crash or denial of service and, via the out-of-bounds read, potential disclosure of kernel memory contents; there is no evidence of memory corruption leading to code execution, and this is a local-only issue. Reachability is narrow: the vulnerable property is exposed only on kernels built with AMD_PRIVATE_COLOR (not enabled in mainstream distribution kernels) and only on systems with an AMD GPU using the amdgpu/DC display path. No public exploit code and no confirmed active exploitation were identified at time of analysis, and vendor patches are available in the stable trees (6.12.110, 6.18.51, 7.2.5) and in mainline 7.3-rc1.
Integer overflow in the Linux kernel's amdgpu VCN decode-message parser lets an authenticated local user with access to the AMD GPU device node bypass a buffer-count bounds check and drive the parser loop far past the end of a message buffer object, producing out-of-bounds kernel reads that crash the system (availability) and can disclose kernel memory (confidentiality). Exploitation is not remote or unauthenticated: the attacker must be a local principal able to submit VCN decode messages and must additionally allocate a roughly 4 GiB GPU-accessible mapping so msg[1] passes the earlier 'header does not fit in BO' check, a substantial resource precondition that our assessment scores as high attack complexity (CVSS:3.1/AV:L/AC:H/PR:L/UI:N/S:U/C:H/I:N/A:H). No public exploit code was identified at time of analysis and the issue is not listed as confirmed actively exploited (CISA KEV); this is a genuine but modest-priority local vulnerability.
Linux kernel AMD KFD (amdkfd) SVM migration code can use an uninitialized return value when migrating a VM range whose CPU side is a hole, causing the driver to tear down all VRAM pages it has just allocated and leaving memory state inconsistent. Affected are Linux kernel builds using the AMD GPU compute path (SVM/HMM migration to VRAM on ROCm/HSA-capable AMD hardware); the flaw affects code reachable from the commit 1da177e4c3f41524e886b7f1b8a0c1fc7321cac2 baseline and is fixed in 6.18.51, 7.2.5 and 7.3-rc1. Triggering requires a local user holding a GPU device handle and hitting a racy, non-default memory-layout condition, and no public exploit code was identified at time of analysis; the vendor's CVSS 3.1 score of 7.8 is assessed as overstated relative to this local, condition-gated error-handling defect.
Uninitialized physical address use in the AMD PMC driver (`amd_stb_s2d_init()`) causes the Linux kernel to call `devm_ioremap()` with physical address zero when the SMU rejects a command with error 0xff, mapping the first 16 MB of physical RAM into kernel virtual address space. Affected systems are AMD-based Linux hosts where the System Management Unit returns an error during S2D (System Trace Buffer) initialization at driver probe time. No public exploit exists and EPSS is 0.20%, consistent with the hardware-gated trigger; fixes are available in Linux 6.18.50 and 7.2.4 stable branches.
Incomplete error-path cleanup in the AMD PMC driver (`platform/x86/amd/pmc`) corrupts the kernel's global LPS0 s2idle linked list when `amd_stb_s2d_init()` fails during module probe, leaving a dangling registered handler whose backing `devm`-managed memory has been freed. On AMD-based x86 Linux systems running an affected kernel, this causes a kernel BUG (`list_add corruption`) upon module reload and a use-after-free condition on any subsequent suspend-to-idle (s2idle) transition. No public exploit exists and EPSS is 0.20% (10th percentile), but the failure condition can arise naturally on long-running systems or specific SMU firmware, making this a realistic local denial-of-service and a potential kernel code-execution path on vulnerable AMD hardware.
Use-after-free in the Linux kernel's AMD MP2 I2C driver (i2c-amd-mp2) enables local low-privileged users to corrupt kernel memory, potentially achieving privilege escalation or system crash on AMD hardware. The flaw occurs during driver probe: when i2c_add_adapter() fails, devres frees the platform I2C context, but the MP2 PCI driver retains a stale pointer in its IRQ and system-sleep callback table, allowing subsequent dereference of freed memory. No public exploit exists and EPSS is 0.18% (7th percentile), reflecting the hardware-specific and error-path-dependent nature of this flaw; vendor-released patches are available across all major stable kernel branches.
Incorrect TLB flush address targeting in the Linux kernel's zap_pte_range memory management function exposes systems running kernel versions prior to 7.1.9 and 7.2 to local privilege escalation and information disclosure, particularly on AMD systems with EFER.TCE enabled and Intel systems using INVPCID. A low-privileged local attacker can exploit a race where the kernel flushes the wrong virtual address after freeing a page table, leaving stale CPU paging-structure-cache entries that can be speculatively accessed or cause the freed table to be reused with potentially attacker-controlled data. No public exploit code or active exploitation (CISA KEV) has been confirmed at time of analysis, and the 0.20% EPSS score reflects the complexity of reliable exploitation.
Use-after-free in the Linux kernel's AMD GPU power management subsystem (drm/amd/pm) allows a low-privileged local attacker to corrupt kernel memory via a race condition in the sysfs power table interface. The flaw exists because amdgpu_dpm_get_pp_table() returns a raw pointer to a driver-owned buffer after releasing adev->pm.mutex, enabling a concurrent pp_table write to free the allocation while a sysfs copy is still in progress. No public exploit has been identified and EPSS probability is very low (0.15%), but the CVSS 7.8 C:H/I:H/A:H impact reflects credible potential for local privilege escalation or kernel crash on AMD GPU-equipped Linux systems.
Divide-by-zero panic in the Linux kernel's AMD display driver (drm/amd/display) allows a low-privileged local user to crash the kernel by triggering a zero-area viewport condition in the calculate_mcache_setting function. The vulnerable code path exits early with num_mcaches == 0 and mvmpg_width/height == 0, then proceeds to divide by those zero values, causing both a divide-by-zero panic and potential integer underflow on num_mcaches. EPSS is very low at 0.15% (5th percentile) and no active exploitation or public exploit code has been identified at time of analysis; however, the local trigger mechanism via display mode setting is accessible to low-privileged users on systems with AMD GPU hardware.
Out-of-bounds slab read in the Linux kernel's ASoC AMD ACP SoundWire legacy machine driver allows a local attacker - or a hardware-triggered probe path - to read beyond an allocated array in create_sdw_dailinks(), potentially causing kernel memory disclosure or denial of service. The vulnerability is introduced when all DAI link entries are initialized, causing the boundary-unchecked loop to walk past the end of the soc_dais allocation. KASAN confirmed the read-of-size-1 in mc_probe(). EPSS is at 0.17% (6th percentile) and the vulnerability is not listed in CISA KEV; no public exploit has been identified at time of analysis. Fixes are available for Linux stable branches 6.18.40 and 7.1.5, as well as the 7.2-rc1 mainline.
Out-of-bounds array read in the Linux kernel's AMD ACP SoundWire SOF audio driver exposes kernel memory to local attackers on systems equipped with AMD SoundWire hardware. The flaw in create_sdw_dailinks() allows iteration past the end of the allocated sof_dais array when all entries are initialized, lacking any bounds guard on the loop termination condition. No active exploitation is recorded (EPSS 0.17%, 6th percentile; no CISA KEV entry), and patches are available across multiple Linux stable branches.
Kernel page fault in Linux kernel AppArmor's file auditing path allows a local low-privileged user to crash the system or leak kernel memory via the audit log. The regression was introduced by commit 4a134723f9f1, which left the *name pointer uninitialized when path->dentry is the aa_null sentinel, then passed it to audit_log_untrustedstring() where strlen() dereferences an invalid address. No public exploit code exists and EPSS probability is 0.17% (7th percentile), but patched stable releases 6.18.40, 7.1.5, and 7.2-rc1 are confirmed available.
Timing side-channel in AMD Vitis Libraries' ECDSA secp256k1 Security Module exposes private cryptographic keys to local attackers via statistical analysis of operation timing or electromagnetic emanations. Affected are versions prior to 2026.1 of the Vitis Libraries Security Module and Vitis Unified Installer for FPGAs and Adaptive SoCs on Windows. AMD has released version 2026.1 as the fix; no public exploit or active exploitation has been identified at time of analysis.
Use-after-free in the Linux kernel AMD IOMMU driver allows a local low-privileged attacker on multi-CPU AMD systems to corrupt kernel memory by exploiting a logical race in `iommu_completion_wait()`. The `need_sync` flag was read locklessly, enabling a CPU to return without waiting for hardware IOMMU command completion while another CPU's page-table pages are freed - leaving the IOMMU walking stale, potentially freed memory. No public exploit exists and EPSS is 0.20% (10th percentile), but successful exploitation on AMD virtualization infrastructure could cross IOMMU isolation boundaries affecting co-tenant VMs.
Double-free and use-after-free conditions in the Linux kernel's drm/amd/display subsystem expose systems with AMD GPU hardware to potential privilege escalation or kernel crash. The flaw resides in dm_update_crtc_state(), where the skip_modeset path releases a display stream reference without nullifying the pointer, leaving it dangling for a second release if a subsequent error - such as a color management failure - triggers the fail label. Patches are confirmed across multiple stable branches (6.6.148, 6.12.101, 6.18.42, 7.1.6, and 7.2-rc4); no public exploit exists and EPSS sits at 0.17% (6th percentile), but the kernel-level memory corruption class demands prioritized patching on AMD GPU deployments.
A stack buffer overflow in the AMD display driver (dc_process_dmub_aux_transfer_async) within the Linux kernel allows a local authenticated attacker with low privileges to potentially execute arbitrary code or crash the system. The flaw arises from missing bounds checks on payload length and link_index, impacting all kernels before the patched versions. While no active exploitation or public proof-of-concept is reported, the issue affects a wide range of systems with AMD GPUs.
Out-of-bounds read in the Linux kernel's AMD IOMMU debugfs subsystem exposes local users with standard privileges to potential kernel memory disclosure or denial of service via a sign-extension defect. The functions iommu_mmio_write() and iommu_capability_write() declare offset variables as signed int but populate them with kstrtou32_from_user(), allowing values in the range 0x80000000-0xFFFFFFFF to wrap negative and theoretically index before the intended MMIO region. The vulnerability description explicitly characterizes it as latent, acknowledging that three pre-existing defensive layers already prevent exploitation in practice; the fix replaces the unsigned parser with kstrtos32_from_user() and adds explicit negativity checks. No public exploit exists, no KEV listing is present, and EPSS sits at 0.15% (5th percentile).
Denial of service in the Linux kernel's KVM/SVM AVIC (Advanced Virtual Interrupt Controller) IPI virtualization affects Hygon Family 18h hosts, where a hardware erratum (#1235, shared with AMD Zen1 Family 17h) lets the CPU read a stale IsRunning bit during ICR write emulation and skip the expected AVIC_IPI_FAILURE_TARGET_NOT_RUNNING VM-Exit. As a result KVM misses the wakeup of a blocking target vCPU, causing hung vCPUs and unbounded stalls in guest execution. EPSS is low (0.17%, 6th percentile) and there is no public exploit identified at time of analysis; the fix disables AVIC IPI virtualization on these CPUs so every non-self IPI is correctly emulated via VM-Exit.
Out-of-bounds read in the AMD display (amdgpu) driver of the Linux kernel occurs when the GPIO pin table parsers get_gpio_i2c_info() and bios_parser_get_gpio_pin_info() trust the VBIOS table_header.structuresize field and iterate over gpio_pin[] entries without confirming the full claimed size is mapped. On a system with a malformed or oversized VBIOS structuresize, the loop reads past the end of the BIOS image, potentially disclosing adjacent kernel memory or crashing the driver. There is no public exploit identified at time of analysis, EPSS is low (0.17%), and the issue is not listed in CISA KEV; a vendor patch is available across multiple stable trees.
Out-of-bounds read in the Linux kernel's AMD Display (amdgpu DRM) DisplayPort code allows a local attacker - or a malicious/attacker-controlled DisplayPort sink - to trigger a one-element over-read of the aux_rd_interval[] array in dp_get_eq_aux_rd_interval(). The array in struct dc_lttpr_caps holds only MAX_REPEATER_CNT-1 (7) entries but is indexed with an offset up to MAX_REPEATER_CNT (8) when a sink advertises 8 LTTPR repeaters via DPCD, reading aux_rd_interval[7]. There is no public exploit identified at time of analysis, EPSS risk is low (0.17%, 6th percentile), and the vendor has released fixed kernel versions.
Heap overflow in the Linux kernel's AMD GPU display driver (drm/amd/display) arises because dal_vector_reserve() computes its allocation size as "capacity * struct_size" in 32-bit arithmetic, which can silently wrap to a small value and cause krealloc() to return an undersized buffer. A local, low-privileged user with access to the DRM/amdgpu device can trigger out-of-bounds heap writes on subsequent vector appends, potentially corrupting kernel memory. There is no public exploit identified at time of analysis, and the EPSS score is low (0.19%, 9th percentile); the issue is fixed and rated CVSS 7.0 (High).
Local privilege escalation and memory corruption in the Linux kernel DRM/GEM subsystem stems from a race condition in the GEM change_handle ioctl when it runs concurrently with gem_close, where botched two-stage idr_replace handling against the wrong idr slot allows a concurrent close to steal the object's only inherited reference. The flaw affects systems using the DRM graphics stack (notably AMD GPU paths, per source tags) and an unprivileged local user with access to a DRM render/card device can trigger a use-after-free, with the upstream resolution disabling the change_handle ioctl entirely until the locking can be proven correct. No public exploit identified at time of analysis and EPSS is low (0.17%, 7th percentile), consistent with a local-only, hard-to-win race rather than mass exploitation.
Out-of-bounds read and unbounded-iteration denial of service in the Linux kernel's AMD Display (amdgpu DC) driver arises when the bios_parser/bios_parser2 code walks VBIOS record chains that lack a proper 0xFF terminator record. A local attacker able to supply a malformed VBIOS image can force hundreds of thousands of probe-time iterations (with record_size=1) and, near the image boundary, trigger struct casts that read past the 2-byte header validated by GET_IMAGE. There is no public exploit identified at time of analysis, and the EPSS score is low (0.17%, 6th percentile), consistent with a local, firmware-dependent memory-safety bug rather than a broadly exploited remote flaw.
Out-of-bounds kernel heap write in the AMD Display (amdgpu) driver's HDMI HDCP 2.x repeater authentication path affects Linux kernels from 5.6 through the 7.1 release candidates. When reading a downstream sink's RxStatus register, the driver in mod_hdcp_read_rx_id_list() uses an attacker-influenced 10-bit message-size field (up to 1023 bytes) as the I2C read length without bounding it to the 177-byte rx_id_list buffer, so a malicious HDMI repeater can force a write past the buffer and corrupt kernel memory. There is no public exploit identified at time of analysis and EPSS is low (0.21%, 11th percentile); it is not listed in CISA KEV.
Out-of-bounds heap write in the Linux kernel amdgpu DRM display driver (drm/amd/display) arises because the VBIOS integrated info tables (v1_11 and v2_1) expose unvalidated u8 HdmiRegNum and Hdmi6GRegNum fields that are used as loop bounds when copying retimer I2C settings into fixed-size arrays (9 and 3 elements). A malformed VBIOS can set these counts up to 255, overrunning the destination arrays during driver probe on AMD GPU systems. No public exploit has been identified and EPSS is very low (0.17%), but the memory-corruption primitive (CWE-787) carries high confidentiality, integrity, and availability impact per the CVSS 7.8 rating.
Improper DMA-alias handling in the Linux kernel's AMD IOMMU driver lets a stale or incorrect Device Table Entry (DTE) be propagated to an alias PCI device, weakening the DMA isolation the IOMMU is meant to enforce. The flaw affects systems on AMD platforms where pci_for_each_dma_alias() supplies an alias-rather than the original-device to clone_alias(), causing the wrong source devid to be used when copying the DTE. EPSS is low (0.17%, 6th percentile) and there is no public exploit identified at time of analysis.
Man-in-the-middle attacks against AMD's optional desktop tools - AMD Management Console (AMC), AMD Ryzen Master, and AMD μProf - can lead to arbitrary code execution because the affected utilities transport data over plaintext HTTP rather than TLS. An attacker positioned on the network path between a victim workstation and the AMD endpoint can tamper with traffic (most plausibly update or telemetry channels) to substitute malicious content that is then executed by the tool. No public exploit identified at time of analysis and the issue is not in CISA KEV; EPSS data was not provided.
Out-of-bounds array access in the Linux kernel's AMD GPU display driver (drm/amd/display) allows local privileged users to trigger memory corruption via the dcn35_stream_encoder_create() function when eng_id equals ENGINE_ID_DIGF (value 5) or is negative, indexing past the 5-element stream_enc_regs[] array. The flaw stems from a faulty boundary check using <= instead of <, and no public exploit has been identified at time of analysis with an EPSS score of 0.02% (5th percentile) indicating very low exploitation probability.
Local privilege escalation and information disclosure in the Linux kernel on AMD Zen2 CPUs allows low-privileged users to trigger instruction corruption via improper isolation of shared resources in the op cache. Affecting kernels prior to 5.10.256, 5.15.207, 6.1.173, 6.6.139, 6.12.88, 6.18.30, and 7.0.7, the flaw carries a CVSS 8.8 due to scope change (S:C) impacting confidentiality, integrity, and availability beyond the original security boundary. EPSS is very low (0.02%, 7th percentile) and no public exploit identified at time of analysis, but the architectural nature of the bug (CPU op cache sharing) makes it relevant for multi-tenant and virtualization workloads.
Denial of service in the Linux kernel Ceph client allows local users with access to a Ceph-mounted filesystem to trigger d_hash list corruption and RCU stalls by inducing path lookups against reused cached negative dentries. The flaw stems from fs/ceph/dir.c calling d_add(dentry, NULL) on already-hashed negative dentries, creating self-loops in the hlist_bl bucket that cause __d_lookup() to spin indefinitely. EPSS is 0.02% (5th percentile) and no public exploit identified at time of analysis, but the bug has been reproduced organically in production (RCU stall on a Dell PowerEdge R7615 running 6.18.17).
Local privilege escalation potential in the Linux kernel's AMD KFD (Kernel Fusion Driver) debug subsystem allows a local user with GPU access to trigger a buffer overflow in the watch_points array via a crafted watch_id value. The flaw stems from signed/unsigned integer mishandling in kfd_dbg_trap_clear_dev_address_watch(), where userspace-supplied watch_id values exceeding INT_MAX cause undefined bit shifts and out-of-bounds memory access. No public exploit identified at time of analysis, and EPSS scores exploitation probability at only 0.02%.
Remote unauthenticated manipulation of AMD Instinct GPU configuration is possible in the AMD Device Metrics Exporter (DME), a ROCm-ecosystem monitoring component, because the service binds to an unrestricted IP address and exposes its control surface network-wide. Any attacker able to reach the listening port can push unauthorized GPU configuration changes, degrading or denying availability of the affected AMD Instinct MI-series accelerator (MI210/MI250/MI250X/MI300A/MI300X/MI308X/MI325X/MI350X/MI355X). No public exploit is identified at time of analysis, and EPSS is low (0.20%), but the CVSS 4.0 base score of 9.2 reflects trivial network reachability with high availability impact.
Insecure installation directory permissions in AMD chipset driver allow local authenticated attackers to achieve SYSTEM-level privilege escalation and execute arbitrary code. The vulnerability affects nearly all AMD Ryzen, Threadripper, EPYC, and Athlon processors across desktop, mobile, embedded, and server product lines. AMD has released patched chipset driver versions 8.01.20.513 (consumer/workstation) and 8.03.14.329/8.03.16.641 (server). No active exploitation confirmed at time of analysis, but the local vector and low attack complexity make this exploitable by any authenticated Windows user, including standard users without admin rights.
AMD IOMMU completion wait operations in the Linux kernel can trigger soft lockups under high load when strict mode is enabled (iommu.strict=1). The vulnerability stems from busy-waiting inside a spinlock with interrupts disabled, causing kernel responsiveness issues and potential denial of service on systems with AMD IOMMU hardware. Patches are available across multiple kernel stable branches (6.6.128, 6.12.75, 6.18.16, 6.19.6, 7.0). EPSS score is low (0.02%, 5th percentile) with no confirmed active exploitation or public POC identified at time of analysis.
Use-after-free in Linux kernel AMD GPU driver allows local authenticated users to potentially execute arbitrary code, escalate privileges, or cause denial of service. The amdgpu_amdkfd_submit_ib() function in the AMD KFD (Kernel Fusion Driver) prematurely releases a DMA fence reference before waiting on it, creating a race condition where the fence memory may be freed before use. Vendor-released patches are available for multiple stable kernel branches (6.1.168, 6.6.131, 6.12.80, 6.18.21, 6.19.11, 7.0). EPSS exploitation probability is very low at 0.02% (7th percentile), and no public exploit or active exploitation has been identified at time of analysis.
Use-after-free in Linux kernel AMD display driver allows local authenticated users to execute arbitrary code, corrupt memory, or cause denial of service. Affects systems with AMD graphics using Display Stream Compression (DSC) and multi-stream transport (MST), particularly laptops with integrated displays and external DP-MST monitors. The vulnerability arises when mode changes occur simultaneously with DSC reconfigurations, causing improper stream lifecycle management. Vendor patch available across multiple kernel versions (6.12.80, 6.18.21, 6.19.11, 7.0). EPSS score of 0.02% indicates low exploitation probability in the wild, with no CISA KEV listing or public exploit identified at time of analysis.
The Handlebars npm package precompiler (bin/handlebars) allows arbitrary JavaScript injection through unsanitized string concatenation in four distinct code paths: template filenames, namespace option (-n), CommonJS path option (-c), and AMD path option (-h). Attackers who can control template filenames or CLI arguments can inject code that executes when the generated JavaScript bundle is loaded in Node.js or browser environments. Publicly available exploit code exists with multiple proof-of-concept vectors demonstrated, including file system manipulation via require('fs'). CVSS 8.3 reflects local attack vector requiring low privileges and user interaction, with changed scope allowing high confidentiality, integrity, and availability impact.
Attested TLS relay attacks in Cocos AI confidential computing system versions 0.4.0 through 0.8.2 enable attackers to impersonate genuine TEE-protected services on AMD SEV-SNP and Intel TDX platforms by extracting ephemeral TLS private keys and redirecting authenticated sessions. The architectural flaw allows an attacker with physical access or side-channel capabilities to relay attestation evidence to a different endpoint, breaking the authentication binding between the TEE and the client. No vendor-released patch is available; the vulnerability affects a specialized confidential computing platform with low EPSS probability (formal EPSS score not provided in input) and no public exploit identified at time of analysis, though formal ProVerif verification confirms the attack feasibility.
In the Linux kernel, the following vulnerability has been resolved: KVM: Don't clobber irqfd routing type when deassigning irqfd When deassigning a KVM_IRQFD, don't clobber the irqfd's copy of the IRQ's routing entry as doing so breaks kvm_arch_irq_bypass_del_producer() on x86 and arm64, which explicitly look for KVM_IRQ_ROUTING_MSI.
On BIG-IP versions 16.0.x before 16.0.1.1, 15.1.x before 15.1.2.1, 14.1.x before 14.1.4, 13.1.x before 13.1.3.6, and 12.1.x before 12.1.5.3 amd BIG-IQ 7.1.0.x before 7.1.0.3 and 7.0.0.x before. Rated critical severity (CVSS 9.8), this vulnerability is remotely exploitable, no authentication required, low attack complexity. Public exploit code available and no vendor patch available.
Boot-time arbitrary code execution is possible on AMD Versal Adaptive SoCs and related Alveo accelerator cards, but only when USB boot mode has been enabled through physical board modifications - a configuration AMD explicitly describes as non-default. A crafted boot image delivered over USB can trigger an out-of-bounds write (CWE-787) that overflows a buffer and overwrites an active function pointer, yielding high confidentiality, integrity, and availability impact confined to the boot process. Because exploitation requires both physical access to the device and a deliberately modified board, plus a non-trivial (high-complexity) overflow, realistic risk is limited to supply-chain, manufacturing, or evil-maid scenarios; no public exploit identified at time of analysis, and no confirmed in-the-wild activity, though the vendor bulletin AMD-SB-8028 documents the issue.
Denuvo Anti-Tamper (through 2026-03-04) can be bypassed by locally authenticated administrators with kernel-level privileges who load a hypervisor driver that intercepts CPUID instructions and spoofs hypervisor-absence results, defeating the anti-tamper check on AMD (SimpleSvm.sys) and Intel (hyperkd.sys, hyperhv.dll) platforms. The vulnerability has a CVSS score of 1.9 (AV:L/AC:H/PR:H) and only affects the integrity of the DRM check on the attacker's own system, with no third-party victim or escalation. No public exploit identified at time of analysis.
In the Linux kernel, the following vulnerability has been resolved: ASoC: amd: yc: fix memory leak in acp6x_pdm_dma_close() acp6x_pdm_dma_close() does not free the runtime->private_data buffer allocated in acp6x_pdm_dma_open(). Add the missing kfree.
In the Linux kernel, the following vulnerability has been resolved: iommu/amd: Do not reallocate GA log buffers on resume Commit c5e1a1eb9279 ("iommu/amd: Simplify and Consolidate Virtual APIC (AVIC) Enablement") moved the GA log allocation from iommu_init_pci() to enable_iommus_vapic(), which is called on every resume. iommu_init_ga_log() assigns iommu->ga_log and iommu->ga_log_tail unconditionally. Each resume therefore replaces the boot-time pointers and leaks both old allocations. The function also uses GFP_KERNEL from a syscore resume callback, where interrupts are disabled and the non-boot CPUs are offline. Return early if both buffers are already allocated. Clear the pointers in free_ga_log() so a partial allocation failure cannot leave ga_log dangling.
In the Linux kernel, the following vulnerability has been resolved: x86/amd_node: Fix potential NULL pointer dereference amd_smn_read/write() are exported functions around __amd_smn_rw(), so they are always available even if amd_smn_init() fails. In that case, 'amd_roots' is NULL and __amd_smn_rw() will access uninitialized memory. Then, commit: 83518453074d ("x86/amd_node: Add SMN offsets to exclusive region access") added the 'smn_exclusive' flag, which indicated the calls to pci_request_config_region_exclusive() succeeded, to prevent concurrent userspace access. Commit: 0a4b61d9c2e4 ("x86/amd_node: Fix AMD root device caching") re-ordered initialization so pci_request_config_region_exclusive() is called earlier and a failure exits amd_smn_init() before allocating 'amd_roots'. The setting of 'smn_exclusive' moved to the end of amd_smn_init(), after 'amd_roots' is allocated. It became redundant and can be removed. Replace 'smn_exclusive' with directly checking 'amd_roots', to fix a potential NULL pointer dereference and to simplify the logic. [ bp: Reorg commit message, touchup comment. ] [ mingo: Rebase & further touchups. ]
In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Avoid DPMS-on for phantom stream [Why & How] Calling dc_update_planes_and_stream separately for stream and its phantom stream causes a NULL pointer dereference, since the phantom is destroyed on the first call. Skip the call for phantom streams.
In the Linux kernel, the following vulnerability has been resolved: drm/amd/pm: bound pp_dpm_set_pp_table() memcpy The powerplay path allocates hardcode_pp_table once with kmemdup(..., soft_pp_table_size). memcpy(..., size) used the sysfs store count (up to PAGE_SIZE) with no upper bound, causing heap overflow. Reject writes where size exceeds soft_pp_table_size.
In the Linux kernel, the following vulnerability has been resolved: drm/amd/powerplay: fix VoltageObjectInfo zero-stride loop and OOB read Reject voltage objects whose usSize is smaller than the header or would advance the cursor past the table end, preventing an infinite loop or heap OOB read when the VBIOS supplies a malformed VoltageObjectInfo table.
In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Fix DM I2C teardown race DM I2C adapters can remain visible to userspace while DM teardown is already in progress. A concurrent i2c-dev transfer may then enter amdgpu_dm_i2c_xfer() after the backing DM state has been torn down, leading to a NULL pointer dereference. Create a devres group around the DM I2C adapter lifetime and release it at the start of dm_hw_fini(), before HPD, IRQ, and DM state are torn down. This removes the I2C adapters first and waits for in-flight users to drain before the structures used by amdgpu_dm_i2c_xfer() disappear. This fixes a teardown ordering race seen during device removal: BUG: kernel NULL pointer dereference RIP: amdgpu_dm_i2c_xfer+0x122/0x1c0 [amdgpu] Call Trace: __i2c_transfer i2c_transfer i2cdev_ioctl_rdwr
In the Linux kernel, the following vulnerability has been resolved: iommu/amd: Fix undefined behavior in devid_write debugfs function When for_each_pci_segment() loop completes without finding a matching segment, the pci_seg pointer is not NULL but points to an invalid memory location (the list head). Accessing pci_seg->id after the loop causes undefined behavior. Fix this by handling the successful case inside the loop and returning -EINVAL after the loop if no matching segment is found.
In the Linux kernel, the following vulnerability has been resolved: cpufreq: amd-pstate-ut: Skip tests when amd-pstate driver is not active The crash issue may occur when modprobe amd_pstate_ut on intel platform. amd_pstate_ut: 1 amd_pstate_ut_acpi_cpc_valid success! amd_pstate_ut: 2 amd_pstate_ut_check_enabled success! BUG: kernel NULL pointer dereference, address: 0000000000000080 #PF: supervisor read access in kernel mode #PF: error_code(0x0000) - not-present page PGD 0 P4D 0 Oops: 0000 [#1] SMP NOPTI CPU: 0 PID: 20300 Comm: modprobe Kdump: loaded Tainted: G O 6.6.0-0010.rc1.ctl4.x86_64 #1 Hardware name: FiberHome R2200 V5/Xeon Boards, BIOS 3.1a 02/24/2020 RIP: 0010:amd_pstate_ut_check_perf+0x141/0x280 [amd_pstate_ut] Call Trace: <TASK> amd_pstate_ut_init+0x1b/0xff0 [amd_pstate_ut] ? __pfx_amd_pstate_ut_init+0x10/0x10 [amd_pstate_ut] do_one_initcall+0x42/0x2e0 ? kmalloc_trace+0x26/0x90 do_init_module+0x60/0x240 __se_sys_init_module+0x185/0x1c0 do_syscall_64+0x62/0x190 entry_SYSCALL_64_after_hwframe+0x76/0x7e </TASK> Add state detection to amd pstate driver to prevent amd_pstate_ut driver from testing on non-AMD platforms. (ML: adjust title)
In the Linux kernel, the following vulnerability has been resolved: cpufreq/amd-pstate: handle missing policy in dynamic EPP callbacks cpufreq_cpu_get() returns NULL when no cpufreq policy is associated with the requested CPU, for example because the CPU is offline or the policy has already been torn down. Both amd_pstate_power_supply_notifier() and amd_pstate_profile_set() acquire a policy via cpufreq_cpu_get() and then pass that pointer to amd_pstate_get_balanced_epp() and amd_pstate_set_epp(), which dereference it unconditionally. A racing CPU hotplug or driver teardown can therefore lead to a NULL pointer dereference on either of these dynamic EPP paths. The third cpufreq_cpu_get() caller in this file, amd_pstate_verify(), already handles the NULL case. Bring the two new callers in line with that pattern: return NOTIFY_OK from the power-supply notifier (matching the other "nothing to do" exits) and -ENODEV from amd_pstate_profile_set() (the usual cpufreq error for a missing CPU policy). Found by code inspection; not tested on hardware.
In the Linux kernel, the following vulnerability has been resolved: i3c: dw: avoid shift-out-of-bounds when DAA assigns no devices On an empty bus ENTDAA assigns nothing, so cmd->rx_len (the count of addresses left unassigned) equals master->maxdevs. The GENMASK() index master->maxdevs - cmd->rx_len - 1 then becomes -1, which trips up UBSAN. This happens every time on boot on a Gigabyte/AMD server: UBSAN: shift-out-of-bounds in drivers/i3c/master/dw-i3c-master.c:905:12 shift exponent 64 is too large for 64-bit type 'long unsigned int' CPU: 7 UID: 0 PID: 963 Comm: (udev-worker) Not tainted 7.0.11-200.fc44.x86_64 #1 PREEMPT(lazy) Hardware name: Giga Computing E163-Z34-AAH1-000/MZ33-DC1-000, BIOS R32_F45 04/01/2026 Call Trace: <TASK> dump_stack_lvl+0x5d/0x80 ubsan_epilogue+0x5/0x2b __ubsan_handle_shift_out_of_bounds.cold+0xd7/0x1ab dw_i3c_master_daa.cold+0x1b/0x96 [dw_i3c_master] i3c_master_do_daa_ext.part.0+0x3e/0xf0 [i3c] Skip the mask when no new device was assigned.
In the Linux kernel, the following vulnerability has been resolved: media: amd: isp4: release partial allocations in isp4if_alloc_fw_gpumem() isp4if_alloc_fw_gpumem() allocates several GPU memory pools in sequence. If one of them fails, it jumps to error_no_memory and returns -ENOMEM without releasing the pools that were already allocated, leaking them. Release the already-allocated pools before returning. isp4if_gpu_mem_free() is a no-op on pools that were not allocated, so calling isp4if_dealloc_fw_gpumem() here safely frees exactly the pools that succeeded. isp4if_gpu_mem_free() previously logged an error for a NULL entry, which is a normal case during partial-allocation cleanup, so make it silent.
In the Linux kernel, the following vulnerability has been resolved: media: amd: isp4: fix self-deadlock in isp4sd_pwron_and_init() error path isp4sd_pwron_and_init() holds ops_mutex via guard(mutex) and, on any init failure, jumps to err_deinit and calls isp4sd_pwroff_and_deinit(). That helper takes the same ops_mutex, re-acquiring a non-recursive mutex already held by the current thread, so any init failure deadlocks. Unwind the error path in stages instead, releasing only what each failure point acquired. This also avoids the issues that an unconditional teardown would hit at the earlier failures, such as a runtime-PM underflow from pm_runtime_resume_and_get() and MMIO access while the device is unpowered.
In the Linux kernel, the following vulnerability has been resolved: platform/x86/amd/hsmp: Reject negative power cap writes in hwmon hsmp_hwmon_write() takes the user-supplied hwmon value as a signed long and assigns "val / MICROWATT_PER_MILLIWATT" to msg.args[0], which is a __u32. MICROWATT_PER_MILLIWATT is an unsigned long, so a negative write to power1_cap (e.g. "echo -1 > power1_cap") is first converted to a huge unsigned value by the division and then stored into the u32 argument. As a result a nonsensical, multi-gigawatt socket power limit is sent to the SMU via HSMP_SET_SOCKET_POWER_LIMIT instead of the write being rejected. Reject negative values with -EINVAL before the conversion. Tested with HSMP enabled: CAP=$(dirname $(grep -l amd_hsmp_hwmon \ /sys/class/hwmon/hwmon*/name | head -1))/power1_cap # negative write echo -1000000 > $CAP ; echo "ret=$?" # valid positive write must still work echo 400000000 > $CAP ; echo "ret=$?" Before: # echo -1000000 > $CAP ; echo "ret=$?" ret=0 <- accepted; bogus limit sent to SMU # echo 400000000 > $CAP ; echo "ret=$?" ret=0 After: # echo -1000000 > $CAP ; echo "ret=$?" bash: echo: write error: Invalid argument ret=1 <- rejected with -EINVAL # echo 400000000 > $CAP ; echo "ret=$?" ret=0 <- valid write still works
In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: fix division by zero in get_estimated_bw() get_estimated_bw() divides by link->dpia_bw_alloc_config.bw_granularity, which is zeroed by reset_bw_alloc_struct() and only populated once DP_TUNNELING_BW_ALLOC_CAP_CHANGED has been handled. link_dp_dpia_handle_bw_alloc_status(), the DPCD interrupt handler, calls get_estimated_bw() whenever DP_TUNNELING_ESTIMATED_BW_CHANGED is set, independently of whether DP_TUNNELING_BW_ALLOC_CAP_CHANGED has ever fired for that link. A connected USB4/DPIA tunneling device that reports an estimated-bandwidth change before ever reporting a capability change drives a division by zero in this IRQ path. link_dpia_send_bw_alloc_request() already guards the same bw_granularity division; add the identical guard here rather than introducing a new pattern. (cherry picked from commit f2a961457c33dc34223aad5c9e8971de34a4eed3)
In the Linux kernel, the following vulnerability has been resolved: dma-buf: dma-heap: don't publish fd before copy_to_user() succeeds DMA_HEAP_IOCTL_ALLOC allocates a dma-buf and installs an fd into the caller's fd table via dma_buf_fd() -> fd_install() before dma_heap_ioctl() copies the result back to userspace. If the trailing copy_to_user() fails, userspace never learns the fd number, but the fd (and the underlying dma-buf reference) are already visible to other threads in the same process and are leaked for the lifetime of the process. The obvious "close it on the failure path" fix is unsafe: once fd_install() has run, another thread can already dup() the fd, send it via SCM_RIGHTS, or close() it and let its number be reused, so a subsequent close_fd() from the ioctl path can operate on an unrelated file. This was pointed out by Christian König on v1 [1]. Restructure the allocation path so that fd_install() is the last, unfailable step of a successful ioctl: 1. heap->ops->allocate() creates the dma_buf. 2. get_unused_fd_flags() reserves an fd number in the caller's fd table without publishing it, so no other thread can observe it. 3. copy_to_user() delivers the fd number to userspace; on failure the fd is returned with put_unused_fd() and the dma_buf reference is dropped with dma_buf_put(), leaving no user- visible state behind. 4. dma_buf_fd_install() publishes the fd and emits the trace_dma_buf_fd tracepoint -- from here on the ioctl cannot fail. A new dma_buf_fd_install() helper is introduced in dma-buf.c to wrap fd_install() together with the DMA_BUF_TRACE() call, preserving the export tracing that dma_buf_fd() provides. dma_heap_ioctl_allocate() is refactored to return the struct dma_buf * directly (returning ERR_PTR on failure) so the caller holds the dmabuf reference across steps 3 and 4. The failure at step 3 is easily reachable from userspace: pass a struct dma_heap_allocation_data that lives in a page whose protection is flipped to PROT_READ between copy_from_user() and copy_to_user() (e.g. via mprotect()). Before this change each such ioctl leaks one dmabuf fd; after it, the fd table is unchanged on failure and only /dev/dma_heap/<name> remains open. No UAPI or heap-driver interface change. [1] https://lore.kernel.org/dri-devel/175e98de-f414-47d7-81c1-c0fe0a8f7f62@amd.com/
In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: avoid divide-by-zero in __is_lut_linear() __is_lut_linear() computes the expected value of each entry with expected = i * MAX_DRM_LUT_VALUE / (size - 1); If it is ever called with a single-entry LUT, size - 1 is zero and the kernel takes a divide error (#DE). A LUT with fewer than two entries cannot describe a linear mapping anyway, so return false early instead of dividing by zero.
In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: fix dc_lock leak on GPU reset error paths On GPU reset, dm_suspend() takes dc_lock and leaves it for dm_resume() to drop. If amdgpu_dm_commit_zero_streams() or dm_dmub_hw_init() fails, the function returns with the lock still held. The matching resume path is then skipped, so every later dc_lock take hangs. Release the cached DC state and unlock before returning the error.
In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Skip Update HDCP Config In Transition State Transition state does not have a valid dm_stream_ctx that should skip configuring HDCP routine. The routine is valid to go through only when a valid stream is created.
In the Linux kernel, the following vulnerability has been resolved: iommu/amd: Put PCI device after handling PPR faults iommu_call_iopf_notifier() looks up the requester with pci_get_domain_bus_and_slot(), which returns a PCI device with its reference count incremented. Neither the successful iommu_report_device_fault() path nor the abort path drops that reference, so every handled PPR request leaks a PCI device reference. This is the same ownership rule that was fixed for the old iommu_v2 ppr_notifier() path by commit 6cf0981c2233 ("iommu/amd: Fix pci device refcount leak in ppr_notifier()"), but iommu_call_iopf_notifier() was added later as a separate PPR/IOPF notifier path. Drop the PCI device reference after handling the PPR entry.
In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: check if dml21_add_phantom_plane() is successful Verify that the phantom plane was allocated to avoid a later segfault. (cherry picked from commit 5adb54abe5a8e82cbff7f8806db30a5f4924329f)
In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: use proper context for logging The same as the rest of the code, get_ss_info_from_atombios() uses calc_pll_cs->ctx->logger for logging. But calc_pll_cs->ctx is initialized only later in calc_pll_max_vco_construct(). Therefore, any output using DC_LOG_SYNC() leads to a NULL pointer deference in get_ss_info_from_atombios(). According to Sashiko, the very same problem exists in dce112_get_pix_clk_dividers() and dcn3_get_pix_clk_dividers() too. To avoid accessing the NULL context, use clk_src->base.ctx->logger everywhere. That context in base is initialized earlier in dce110_clk_src_construct() and dce112_clk_src_construct(). Before get_ss_info_from_atombios() or Sashiko's get_pix_clk_dividers functions above are actually called. This is done by redefining DC_LOGGER to CTX->logger. Before: dce110_clk_src_construct() did: -> sets clk_src->base.ctx = ctx; -> ss_info_from_atombios_create() -> get_ss_info_from_atombios() <- uses calc_pll_cs->ctx # BOOM -> calc_pll_max_vco_construct() <- sets calc_pll_cs->ctx After: dce110_clk_src_construct() does: -> sets clk_src->base.ctx = ctx; -> ss_info_from_atombios_create() -> get_ss_info_from_atombios() <- uses clk_src->base.ctx (cherry picked from commit 6f16fcbb0c46a87e3d9685407e906573d60104b0)
In the Linux kernel, the following vulnerability has been resolved: perf/x86/amd/lbr: Fix kernel address leakage A user-only branch stack can contain branches that originate from the kernel. As a result, kernel addresses are exposed to user space even when PERF_SAMPLE_BRANCH_USER is requested. On AMD processors supporting X86_FEATURE_AMD_LBR_V2, perf can still report SYSRET/ERET entries for which the branch-from addresses are in the kernel. E.g. $ perf record -e cycles -o - -j any,save_type,u -- \ perf bench syscall basic --loop 1000 | \ perf script -i - -F brstack|tr ' ' '\n'| \ grep -E '0x[89a-f][0-9a-f]{15}' ... 0xffffffff81001268/0x717a90a38f1a/M/-/-/0/ERET/NON_SPEC_CORRECT_PATH 0xffffffff81001268/0x717a90a39157/M/-/-/0/ERET/NON_SPEC_CORRECT_PATH 0xffffffff81001268/0x717a90a2c628/M/-/-/0/ERET/NON_SPEC_CORRECT_PATH 0xffffffff81001268/0x717a90a41b60/M/-/-/0/ERET/NON_SPEC_CORRECT_PATH 0xffffffff81001268/0x717a90a260db/M/-/-/0/ERET/NON_SPEC_CORRECT_PATH 0xffffffff81001268/0x717a90a260db/M/-/-/0/ERET/NON_SPEC_CORRECT_PATH 0xffffffff81001268/0x717a8bef1c30/M/-/-/0/ERET/NON_SPEC_CORRECT_PATH 0xffffffff81001268/0x717a8e4d3c90/M/-/-/0/ERET/NON_SPEC_CORRECT_PATH ... The reason is that the hardware filter only considers the privilege level applicable to the branch target. Extend software filtering to also validate the branch-from addresses against br_sel, so that any branch record whose branch-from address is in the kernel is dropped when PERF_SAMPLE_BRANCH_USER is requested.
In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Fix NULL pointer dereference in amdgpu_dm_crtc_set_vblank() amdgpu_dm_crtc_set_vblank() dereferences acrtc_state->stream when vblank is enabled/queried from DRM_IOCTL_MODE_CRTC_GET_SEQUENCE before a stream is attached to it. BUG: kernel NULL pointer dereference, address: 0000000000000008 RIP: amdgpu_dm_crtc_set_vblank+0x6b/0x4d0 [amdgpu] Call Trace: drm_vblank_enable drm_vblank_get drm_crtc_get_sequence_ioctl drm_ioctl_kernel drm_ioctl Reproduced by running VKCTS with WSI tests enabled on RADV. Guard the enable path on acrtc_state->stream being non-NULL, matching the existing checks in this function. (cherry picked from commit 7b1b31bf6942e6f43509b48da23f8e27269aac39)
In the Linux kernel, the following vulnerability has been resolved: perf/x86/amd/brs: Fix kernel address leakage A user-only branch stack can contain branches that originate from the kernel. As a result, kernel addresses are exposed to user space even when PERF_SAMPLE_BRANCH_USER is requested. On AMD processors supporting X86_FEATURE_BRS (Zen 3 only), perf can still report entries such as SYSRET/interrupt returns for which the branch-from addresses are in the kernel. E.g. $ perf record -j any,u -c 4000 -e branch-brs -o - -- \ perf bench syscall basic --loop 1000 | \ perf script -i - -F brstack|tr ' ' '\n'| \ grep -E '0x[89a-f][0-9a-f]{15}' ... 0xffffffff810001c4/0x72e2e32955eb/-/-/-/0//- 0xffffffff810001c4/0x72e2d94a9821/-/-/-/0//- 0xffffffff810001c4/0x72e2d94ffa1b/-/-/-/0//- ... BRS provides no hardware branch filtering, so privilege level filtering is performed entirely in software. However, amd_brs_match_plm() only validates the branch-to address against the requested privilege levels. For branches from the kernel to user space, the branch-from address is left unchecked and is leaked. Extend the software filter to also validate the branch-from address, so that any branch record whose branch-from address is in the kernel is dropped when PERF_SAMPLE_BRANCH_USER is requested.
In the Linux kernel, the following vulnerability has been resolved: accel/amdxdna: reject user command submission without a command BO amdxdna_drm_submit_execbuf() passes the user-supplied command BO handle straight into amdxdna_cmd_submit() with drv_cmd == NULL. When the handle is AMDXDNA_INVALID_BO_HANDLE (0), the block that fetches job->cmd_bo is skipped, leaving it NULL, and no check rejects it on the user path (the !job->cmd_bo guard lives inside the != INVALID branch). The job is then armed and pushed to the DRM scheduler. aie2_sched_job_run() takes the drv_cmd == NULL path and calls amdxdna_cmd_set_state(job->cmd_bo) -> amdxdna_gem_vmap(NULL) -> to_gobj(NULL)->dev, a NULL pointer dereference in the drm_sched worker. A process with access to the accel node on a system with a probed AMD NPU can trigger a kernel oops with a single AMDXDNA_EXEC_CMD ioctl (cmd_handles = 0). Only internal driver commands (SYNC_DEBUG_BO / ATTACH_DEBUG_BO) legitimately pass AMDXDNA_INVALID_BO_HANDLE, and they always set drv_cmd. Reject the invalid handle for user submissions (drv_cmd == NULL) at the submit choke point so every user path is covered. Found by 0sec automated security-research tooling (https://0sec.ai).
In the Linux kernel, the following vulnerability has been resolved: perf/x86/amd/core: Avoid enabling BRS from the SVM reload path Branch Sampling (BRS) and Last Branch Record (LBR) are mutually exclusive hardware features, and users of both are tracked via cpuc->lbr_users. When SVM is toggled on a CPU, the host perf events are reprogrammed to update the HostOnly filter bit (set when virtualization is enabled, cleared when it is disabled). On PerfMonV2-capable processors, this reprogramming is performed by calling amd_pmu_enable_all() to rewrite the event selectors. However, amd_pmu_enable_all() also calls amd_brs_enable_all(), which enables BRS whenever cpuc->lbr_users > 0. Having active LBR events satisfies this gating on processors that have LBR but not BRS. The kernel then tries to set the BRS enable bit in DebugExtnCfg (MSR 0xc000010f). Since that bit is deprecated on such hardware, the write results in a #GP: Call Trace: <IRQ> amd_pmu_enable_all+0x1d/0x90 amd_pmu_disable_virt+0x62/0xb0 kvm_arch_disable_virtualization_cpu+0xa/0x40 [kvm] hardware_disable_nolock+0x1a/0x30 [kvm] __flush_smp_call_function_queue+0x9b/0x410 __sysvec_call_function+0x18/0xc0 sysvec_call_function+0x69/0x90 </IRQ> <TASK> asm_sysvec_call_function+0x16/0x20 RIP: 0010:cpuidle_enter_state+0xc4/0x450 ? cpuidle_enter_state+0xb7/0x450 cpuidle_enter+0x29/0x40 cpuidle_idle_call+0xf5/0x160 do_idle+0x7b/0xe0 cpu_startup_entry+0x26/0x30 start_secondary+0x115/0x140 secondary_startup_64_no_verify+0x194/0x19b </TASK> Fix this by ensuring that BRS is not enabled from the event selector reprogramming path even when cpuc->lbr_users > 0.
Use-After-Free in the AMD Ryzen Master Utility Driver exposes kernel memory to a locally authenticated, high-privileged attacker, with the primary confirmed impact being system availability loss. The vulnerability (CWE-416) resides within the driver component bundled with both the Ryzen Master application and its Monitoring SDK, affecting all versions prior to the patched releases. No public exploit code or active exploitation has been identified at time of analysis, and the CVSS 4.0 score of 5.6 reflects the restricted local, high-privilege attack surface despite the kernel-level nature of the flaw.
DLL hijacking during the AMD Ryzen Master installation process allows a local low-privileged attacker to escalate privileges and execute arbitrary code on Windows systems running affected versions. The flaw, rooted in an uncontrolled DLL search path (CWE-427), affects AMD Ryzen Master up to 3.0.0.4199, Ryzen Master SDK up to 3.0.1.4732, and a legacy branch for Ryzen 3000 Series processors up to 2.14.3.5040. No public exploit code has been identified at time of analysis, and this vulnerability is not listed in the CISA KEV catalog.
Information disclosure in AMD Zen processor microarchitecture, surfaced through Windows system software, enables a local low-privileged attacker to read high-sensitivity data across security boundaries. The CVSS Scope Changed metric (S:C) combined with C:H and the AMD Zen tag strongly suggests a microarchitectural side-channel capable of leaking data from outside the attacker's security context - a pattern consistent with speculative execution or cache-based cross-boundary leakage. No public exploit has been identified at time of analysis, and CISA SSVC rates exploitation status as none; however, the breadth of affected Windows versions (Server 2012 R2 through Server 2025 and Windows 10/11 across all supported channels) gives this a wide potential exposure surface on AMD Zen-equipped systems.
Information disclosure in AMD Zen processors on Windows allows a locally authenticated low-privileged attacker to read sensitive memory contents across security boundaries via a high-complexity microarchitectural technique. Affecting Windows versions from Windows 10 1607 to Windows 11 26H1 and Server 2012 R2 through Server 2025, this vulnerability was reported by Microsoft's security team (secure@microsoft.com) and carries a CVSS 5.6 medium score with Scope:Changed (S:C) indicating the attacker can cross a privilege boundary to reach data outside their own security context. No public exploit code exists and the vulnerability is absent from the CISA KEV catalog, though vendor-released patches are confirmed available via MSRC.
DLL hijacking in AMD Power Design Manager (PDM) enables a local, low-privileged attacker to escalate privileges during the software's uninstallation process, ultimately achieving arbitrary code execution at a higher privilege level. The vulnerability stems from CWE-427 (Uncontrolled Search Path Element), where the PDM uninstaller resolves DLL dependencies from directories writable by unprivileged users. AMD PSIRT confirmed the issue and released an Un-Installer patch at version 2026.1 via Security Bulletin AMD-SB-8016; no public exploit code or CISA KEV listing has been identified at time of analysis.
In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Fix ISM dc_lock deadlock during suspend [Why] System hang observed during suspend/resume while video is playing. amdgpu_dm_ism_disable() is called under dc_lock and waits for ISM delayed work via disable_delayed_work_sync(). The work handlers themselves take dc_lock, producing an ABBA deadlock when a worker is in flight at suspend time. [How] Split the disable path into two phases with opposite locking contracts: 1. amdgpu_dm_ism_disable() -- quiesces workers, must NOT hold dc_lock. 2. amdgpu_dm_ism_force_full_power() (new) -- drives the ISM FSM back to FULL_POWER_RUNNING, must hold dc_lock.
In the Linux kernel, the following vulnerability has been resolved: iommu/amd: Fix IRQ unsafe locking in gdom allocation Lockdep complains: [ 259.410489] ===================================================== [ 259.417287] WARNING: HARDIRQ-safe -> HARDIRQ-unsafe lock order detected [ 259.424667] 7.0.0-g51db1d8d2113 #54 Not tainted [ 259.429718] ----------------------------------------------------- [ 259.436516] qemu-system-x86/10143 [HC0[0]:SC0[0]:HE0:SE1] is trying to acquire: [ 259.444670] ff3b2b1c60305170 (&xa->xa_lock#25){+.+.}-{3:3}, at: __domain_flush_pages+0x17c/0x4b0 [ 259.454485] and this task is already holding: [ 259.460991] ff3b2b1c98504cc0 (&domain->lock){-.-.}-{3:3}, at: amd_iommu_iotlb_sync+0x25/0x60 [ 259.470408] which would create a new lock dependency: [ 259.476041] (&domain->lock){-.-.}-{3:3} -> (&xa->xa_lock#25){+.+.}-{3:3} [ 259.483615] but this new dependency connects a HARDIRQ-irq-safe lock: [ 259.492447] (&domain->lock){-.-.}-{3:3} [ 259.492449] ... which became HARDIRQ-irq-safe at: [ 259.503705] lock_acquire+0xb6/0x2e0 [ 259.507790] _raw_spin_lock_irqsave+0x3e/0x60 [ 259.512748] amd_iommu_flush_iotlb_all+0x20/0x50 [ 259.517996] iommu_dma_free_iova.isra.0+0x1b8/0x1e0 [ 259.523534] __iommu_dma_unmap+0xc2/0x140 [ 259.528100] iommu_dma_unmap_phys+0x55/0xc0 [ 259.532863] dma_unmap_phys+0x274/0x2e0 [ 259.537238] dma_unmap_page_attrs+0x17/0x30 [ 259.542000] nvme_unmap_data+0x13e/0x280 [ 259.546473] nvme_pci_complete_batch+0x45/0x70 [ 259.551524] nvme_irq+0x83/0x90 [ 259.555123] __handle_irq_event_percpu+0x92/0x360 [ 259.560466] handle_irq_event+0x39/0x80 [ 259.564841] handle_edge_irq+0xb2/0x1a0 [ 259.569214] __common_interrupt+0x4e/0x130 [ 259.573882] common_interrupt+0x88/0xa0 [ 259.578256] asm_common_interrupt+0x27/0x40 [ 259.583019] cpuidle_enter_state+0x119/0x5d0 [ 259.587877] cpuidle_enter+0x2e/0x50 [ 259.591962] do_idle+0x153/0x2c0 [ 259.595657] cpu_startup_entry+0x29/0x30 [ 259.600128] start_secondary+0x118/0x150 [ 259.604601] common_startup_64+0x13e/0x141 [ 259.609266] to a HARDIRQ-irq-unsafe lock: [ 259.615384] (&xa->xa_lock#25){+.+.}-{3:3} [ 259.615386] ... which became HARDIRQ-irq-unsafe at: [ 259.627039] ... [ 259.627039] lock_acquire+0xb6/0x2e0 [ 259.633071] _raw_spin_lock+0x2f/0x50 [ 259.637250] amd_iommu_alloc_domain_nested+0x140/0x3c0 [ 259.643078] iommufd_hwpt_alloc+0x272/0x800 [iommufd] [ 259.648813] iommufd_fops_ioctl+0x14e/0x200 [iommufd] [ 259.654547] __x64_sys_ioctl+0x9d/0xf0 ... Since amd_iommu_domain_flush_pages() necessarily holds domain->lock to do the flush, switch the allocation side in gdom_info_load_or_alloc_locked() to HARDIRQ-safe allocation. The IOMMU_DESTROY->free path has the same issue, so switch that path to HARDIRQ-safe locking as well.
In the Linux kernel, the following vulnerability has been resolved: iommu/amd: Bound the early ACPI HID map The ivrs_acpihid command-line parser appends entries to a fixed four-element early_acpihid_map array. Unlike the sibling IOAPIC and HPET parsers, it does not reject a fifth entry before incrementing the map size. Check the capacity at the common found label before parsing the HID and UID or writing the entry.
In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: detect_link_and_local_sink: DP alt mode timeout path leaks prev_sink reference prev_sink is unconditionally retained via dc_sink_retain at function entry, but the DP alt mode timeout path inside SIGNAL_TYPE_DISPLAY_PORT returns false without releasing prev_sink. All other return paths in the function correctly call dc_sink_release(prev_sink), making this the only missing cleanup. (cherry picked from commit 45510cf662dcf46b5d8926d454f338809f107b9d)
In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: dce100: skip non-DP stream encoders for DP MST On DCE8-class ASICs (e.g. Bonaire), the resource pool contains digital DIG stream encoders plus one analog DAC encoder. When assigning a stream encoder for a second DisplayPort MST stream, if the preferred digital encoder is already acquired, dce100_find_first_free_match_stream_enc_for_link() falls back to the first free pool entry. That entry may be the analog encoder, whose funcs table lacks DP hooks such as dp_set_stream_attribute. The subsequent atomic commit then dereferences NULL function pointers in link_set_dpms_on() and crashes. Skip encoders without dp_set_stream_attribute when the stream uses a DP signal (including MST). Use dc_is_dp_signal(stream->signal) for the MST fallback path instead of checking only the link connector signal. Tested on: - GPU: AMD Radeon R7 260X (Bonaire / DCE8) - Board: Supermicro C9X299-PG300 - Setup: DP MST daisy chain, hotplug second monitor or have it connected on boot - Kernel: 7.1.3 (issue observed since 6.19) - Result: kernel oops without patch; dual monitors stable with patch (cherry picked from commit 28ec64943e3ee4d9b8d30cea61e380f1429953a8)
Broadcast TLB flush in the Linux kernel x86 memory management subsystem triggers a General Protection Fault (#GP) on AMD INVLPGB-capable systems booted with the 'nopcid' parameter, causing a kernel panic and local denial of service. When PCID is disabled via 'nopcid', CR4.PCIDE is not set, but the INVLPGB broadcast TLB invalidation path remains enabled; once a memory descriptor becomes active across more than three CPUs, the kernel assigns it a global ASID and issues INVLPGB with a non-zero PCID - an illegal state that crashes the kernel. No public exploit exists, EPSS is 0.17% (6th percentile), and this is not in CISA KEV; real-world impact is constrained to the uncommon 'nopcid' boot configuration on AMD hardware.