Amd

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)

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.

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: drm/amd/display: Check for tg ops in dce110_set_avmute Some older DCE timing generators do not implement is_tg_enabled in their ops table. Calling it unconditionally when waiting for AV mute frames causes a NULL pointer dereference on Southern Islands dGPUs when turning the display off over HDMI. Check that tg and the required ops exist before waiting for frames. (cherry picked from commit 2686a0c0aaa07bec2e24131835cf27b5fd4935a5)

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.

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).

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.

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.

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.

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.

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.

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)

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.

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.

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.

In the Linux kernel, the following vulnerability has been resolved: drm/amdgpu: fix lock leak on ENOMEM in AMDGPU_GEM_OP_GET_MAPPING_INFO The AMDGPU_GEM_OP_GET_MAPPING_INFO branch of amdgpu_gem_op_ioctl() holds three cleanup-tracked resources before calling kvcalloc(): the drm_gem_object reference from drm_gem_object_lookup(), the drm_exec lock on the looked-up GEM via drm_exec_lock_obj(), and the drm_exec lock on the per-process VM root page directory via amdgpu_vm_lock_pd(). All three are released by the out_exec label that every other error path in this function jumps to. The kvcalloc() failure path returns -ENOMEM directly, skipping out_exec and leaking all three. The leaked per-process VM root PD dma_resv lock is the load-bearing leak: any subsequent operation on the same VM (further GEM ops, command-submission, eviction, TTM shrinker callbacks) blocks on the held lock. DRM_IOCTL_AMDGPU_GEM_OP is DRM_AUTH | DRM_RENDER_ALLOW, so this is an unprivileged-local denial of service against the caller's GPU context, reachable by any process with /dev/dri/renderD* access. Route the failure through out_exec so drm_exec_fini() and drm_gem_object_put() run. Reproduced on stock 7.0.0-10, Ryzen 7 5700U / Radeon Vega (Lucienne): the failing ioctl returns -ENOMEM and a second GET_MAPPING_INFO on the same fd then blocks in drm_exec_lock_obj() on the leaked dma_resv. SIGKILL on the caller does not reap the task; the fd-release path during process exit goes through amdgpu_gem_object_close() -> drm_exec_prepare_obj() on the same lock, leaving the task in D state until the box is rebooted. The patched kernel was not rebuilt and re-tested on this hardware; the fix is mechanical. Tested on a single Lucienne / Vega box only. Ziyi Guo posted an independent INT_MAX-bound check for args->num_entries in the same branch [1]; the two patches are complementary and can land in either order. (cherry picked from commit b69d3256d79de15f54c322986ff4da68f1d65b0a)

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).

NULL pointer dereference in the Linux kernel's AMD64 AGP driver crashes systems running in virtualized environments without physical AMD northbridge hardware. Broken error propagation in `agp_amd64_probe()` - comparing `cache_nbs()` return value against exactly `-1` rather than `< 0` - masks the `-ENODEV` error code, allowing the driver to proceed with initialization, ultimately causing a General Protection Fault in `amd64_fetch_size()` when `node_to_amd_nb(0)` returns NULL. No public exploit has been identified at time of analysis, EPSS is 0.18% (7th percentile), and impact is confined to local denial of service via kernel crash; patches are confirmed available across multiple stable branches.

NULL pointer dereference in the Linux kernel's AMD RAS subsystem crashes systems with AMD GPU hardware. The function `ras_core_ras_interrupt_detected()` in `drm/amd/ras` fails to validate the `ras_core` pointer before dereferencing `ras_core->dev` in an error path, enabling a local low-privilege user to trigger a kernel panic and denial of service. No public exploit code exists and the vulnerability is not listed in CISA KEV; EPSS at 0.14% (4th percentile) confirms negligible current exploitation probability. Upstream fix commits are available in stable kernel trees.

NULL pointer dereference in the Linux kernel's drm/amd/ras subsystem allows a local low-privileged user to crash the kernel on systems with AMD GPUs. The flaw in ras_core_get_utc_second_timestamp() occurs when a NULL ras_core pointer passes a conditional check but is then dereferenced in the subsequent error-printing path, producing a kernel panic. No public exploit exists and EPSS sits at 0.15% (4th percentile), placing this firmly as a low-urgency local denial-of-service hardening issue despite the Availability:High CVSS rating.

NULL pointer dereference in the Linux kernel AMD display driver (drm/amd/display) can cause a kernel panic on systems running AMD GPUs, resulting in a complete denial of service. The flaw resides in dc_dmub_srv_log_diagnostic_data() and dc_dmub_srv_enable_dpia_trace() in dc_dmub_srv.c, where a combined NULL guard incorrectly permits DC_LOG_ERROR() - which internally dereferences dc_dmub_srv->ctx - to execute when dc_dmub_srv itself is NULL. No public exploit has been identified at time of analysis and EPSS sits at the 4th percentile, indicating very low exploitation probability in the wild.

Kernel crash in Linux DRM/AMD DCN32 display subsystem affects systems equipped with AMD RDNA3-generation GPUs running x86 non-RT kernels. The dcn32_validate_bandwidth() function locks FPU registers via DC_FP_START(), disabling local softirqs, then calls kvzalloc() for a ~335 KiB phantom-plane allocation that triggers the vmalloc path; vmalloc fires BUG_ON(in_interrupt()), crashing the kernel. No public exploit has been identified at time of analysis, and EPSS at 0.15% (5th percentile) reflects low real-world exploitation interest.

Boot-time kernel crash in Linux 6.16+ on AMD IOMMU-equipped systems causes a General Protection Fault when a PCI device whose Bus:Device.Function address is absent from the ACPI IVRS table is encountered during IOMMU initialization. The root cause is a missing bounds check in __rlookup_amd_iommu() that was latent until commit e874c666b15b changed the rlookup_table allocation from a zeroed page-order block (which returned NULL on overrun) to a tight kvcalloc(), causing adjacent slab contents to be dereferenced as a valid struct amd_iommu pointer. The result is a non-recoverable GPF at boot time, confirmed in production on Google Compute Engine ct6e VMs; no public exploit code and no CISA KEV listing exist at time of analysis.

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.

NULL pointer dereference and buffer over-read in the Linux kernel's AMD display driver (drm/amd/display) can be triggered by a local user writing to the sdp_message debugfs node, causing a kernel panic and denial of service. The dp_sdp_message_debugfs_write() function fails to check whether connector->base.state->crtc is NULL - a valid transient state after GPU hotplug before an atomic commit - and unconditionally passes 36 bytes to copy_from_user() regardless of the caller-provided size, enabling a second over-read path. No public exploit or CISA KEV listing exists; EPSS is 0.18% (7th percentile), consistent with a localized, hardware-dependent DoS.

Memory leak in the Linux kernel's amd-pstate driver allows local availability impact on systems running AMD CPUs when EPP (Energy Performance Preference) initialization fails. The amd_pstate_epp_cpu_init() function allocates a cpudata object at entry but lacks a corresponding free on the error path triggered when setting the EPP value fails, causing kernel heap memory to leak on each failed CPU initialization event. No public exploit exists and EPSS sits at 0.15% (5th percentile), reflecting negligible adversarial interest; risk is primarily operational - repeated CPU hotplug cycles on affected hardware can progressively exhaust kernel memory.

Unsafe NMI-context invocation of perf_allow_kernel() in the Linux kernel's AMD IBS (Instruction Based Sampling) perf handler can cause a fatal kernel crash on AMD-powered systems running affected stable branches from commit 50a53b60e141d7e3 onward. A local user with perf event access on an AMD system can trigger the IBS NMI handler path, inducing a kernel panic or deadlock as the unsupported function call violates NMI-context restrictions. No public exploit has been identified at time of analysis; EPSS is 0.15% (5th percentile), consistent with a niche hardware-specific kernel subsystem flaw with no current exploitation activity.

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.

Unrestricted resource allocation in AMD µProf allows a local low-privileged user to consume excessive system resources, resulting in a loss of availability (denial of service). The CVSS 4.0 score of 6.8 reflects a locally exploitable, low-complexity attack requiring only low privileges with no user interaction needed. No public exploit code has been identified and this vulnerability is not listed in the CISA KEV catalog at time of analysis; however, the straightforward nature of resource exhaustion attacks makes it a realistic local threat on systems where AMD µProf is deployed.

Improper access control in AMD µProf exposes a kernel-shared memory section to low-privileged local users, enabling writes that can crash the system or cause a denial of service. All AMD µProf versions prior to 5.3 are affected across supported platforms. No public exploit code has been identified and this CVE is not listed in CISA KEV, but the CVSS 4.0 vector (AV:L/AC:L/AT:N/PR:L/UI:N) indicates straightforward local exploitation requiring only basic user privileges with no additional complexity or user interaction.

Improper access control in the IOMMU register interface on AMD EPYC server processors allows a high-privileged local attacker to induce non-coherent memory accesses by the AMD Secure Processor (ASP), resulting in loss of system integrity beyond the directly compromised component. Affected processor families span EPYC 8004, 9004, and 9005 series - including embedded variants - covering AMD's current-generation server and embedded datacenter platforms. No public exploit code and no CISA KEV listing exist at time of analysis, but the elevated subsequent integrity impact (SI:H in CVSS 4.0) signals meaningful security boundary degradation, particularly relevant for confidential computing and virtualized environments where ASP integrity is foundational.

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.

Null pointer dereference in the Linux kernel's AMD GPU display driver (drm/amd/display) crashes the kernel during Hot Plug Detection (HPD) initialization on systems with AMD GPUs. The amdgpu_dm_hpd_init() function assigns dc_link from a connector but then unconditionally dereferences it at line 940 of amdgpu_dm_irq.c without first confirming it is non-NULL - connectors lacking a valid dc_link trigger a kernel NULL dereference. Exploitation requires local, low-privileged access to a system with an affected AMD GPU; no public exploit has been identified at time of analysis and EPSS probability is 0.02% (5th percentile), indicating very limited real-world exploitation pressure.

Insufficient granularity of access control in ASP (AMD Secure Processor) may allow an attacker with an untrusted user space application to map sensitive SMN (System Management Network) apertures. Rated high severity (CVSS 7.1). No vendor patch available.

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%.

VM escape in Kata Containers allows any Kubernetes user with pod-creation rights to break out of the VM sandbox and gain full read/write access to the host filesystem. All Kata Containers installations prior to commit ffa59ce3aa78 are affected when using the default configuration.toml, which enables the `virtio_fs_extra_args` and `kernel_params` pod annotations out of the box. An attacker crafts a pod with two annotations: one to redirect virtiofsd to serve the host root filesystem (`/`) into the guest VM, and a second to enable the agent debug console - after which the entire host filesystem is accessible from inside the supposedly isolated VM. A fully working proof-of-concept with confirmed output against Kata Containers 3.28.0 on Ubuntu 24.04 has been publicly disclosed; no public exploit confirmed as actively exploited (CISA KEV) at time of analysis.

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.

A DLL hijacking vulnerability in the AMD Cleanup Utility could allow an attacker to achieve privilege escalation potentially resulting in arbitrary code execution. Rated high severity (CVSS 7.0), this vulnerability is low attack complexity. No vendor patch available.

Improper restriction of operations within the bounds of a memory buffer in the AMD secure processer (ASP) could allow an attacker to read or write to protected memory potentially resulting in. Rated high severity (CVSS 8.8). No vendor patch available.

Improper privilege validation in AMD Secure Processor (ASP) allows authenticated local attackers to write data to restricted memory regions, compromising data integrity and potentially affecting system availability. The vulnerability affects AMD MI-25, MI250, MI210 accelerators and AMD Radeon Pro V520/V620 GPUs. No public exploit code has been identified, but the low attack complexity and authenticated network access vector indicate moderate real-world risk in data center and AI/ML environments where these devices are deployed.

Buffer overflow in AMD GPU driver IOCTL handler enables local privilege escalation to root on Linux systems running AMD Instinct or Radeon Pro GPUs. Authenticated local users with low privileges can exploit an out-of-bounds write vulnerability in the AMDGV_CMD_GET_DIAG_DATA IOCTL to achieve arbitrary kernel code execution. EPSS data not available; no public exploit or CISA KEV listing identified at time of analysis, suggesting limited active exploitation despite high CVSS 8.5 severity.

Out-of-bounds read in AMD Secure Processor TEE SOC Driver allows high-privileged local attackers to trigger memory exposure or denial of service via malformed SR-IOV commands on Radeon RX 6000/7000, Pro W6000/W7000, and Instinct MI-series GPUs. Insufficient parameter sanitization in the DRV_SOC_CMD_ID_LOAD_GFX_IP_FW command handler permits crafted input to bypass bounds checks, exposing SOC Driver memory or causing exceptions. Attack requires high privilege level (PR:H) and local access (AV:L), limiting real-world exploitation to compromised administrative contexts or supply-chain scenarios.

Improperly preserved integrity of hardware configuration state during a power save/restore operation in the AMD Secure Processor (ASP) could allow an attacker with the ability to write outside the. Rated high severity (CVSS 7.1). No vendor patch available.

Improper Input Validation in the AMD RAID driver could allow an attacker to point to an arbitrary memory location potentially resulting in privilege escalation and arbitrary code execution. Rated high severity (CVSS 8.6), this vulnerability is low attack complexity. No vendor patch available.

Local privilege escalation in AMD Platform Management Framework (PMF) allows authenticated attackers with low privileges to execute arbitrary code with elevated system privileges through an out-of-bounds write vulnerability. Affects multiple AMD Ryzen processor series (6000, 7035, 7040, 8040, and Embedded R8000) across mobile and embedded platforms. The CVSS 4.0 score of 8.4 reflects high impact to system integrity and availability with changed scope, indicating the attacker can escape the vulnerable component's security context. No active exploitation confirmed in CISA KEV at time of analysis, and public exploit code availability is not indicated in current intelligence.

Buffer overflow in AMD Sensor Fusion Hub Driver allows local authenticated attackers to write out of bounds, causing denial of service or system crash. The vulnerability affects multiple Ryzen processor families (4000, 5000, 7000, 7020, 7030, 7035, 7040 series and Ryzen AI 300 series) with Radeon integrated graphics across Windows mobile and desktop platforms. No active exploitation has been confirmed at time of analysis.

Arbitrary code execution and denial of service in AMD Platform Management Framework (PMF) affects Ryzen 7035, 7040, 8040 mobile processors and Ryzen Embedded 8000 series. A local authenticated attacker exploiting an unchecked return value vulnerability can write to arbitrary memory locations, potentially escalating privileges from low to high integrity across system boundaries. The CVSS 4.0 score of 7.1 reflects local attack vector with low complexity but requires specific attack timing conditions (AT:P), though the cross-scope impact (S:H) and high confidentiality/integrity impact to subsequent systems elevate real-world risk for enterprise environments with AMD mobile processors.

Out-of-bounds read in AMD Platform Management Framework (PMF) allows authenticated local attackers to read arbitrary memory locations, potentially disclosing sensitive information or causing availability loss on affected Ryzen processors. The vulnerability requires local access and low privileges but can be triggered without user interaction. AMD released a security bulletin (AMD-SB-4015) describing the issue; active exploitation status not confirmed at time of analysis.

Local attackers with low-privilege credentials can exploit unchecked return value handling in AMD Platform Management Framework (PMF) to read or write arbitrary memory addresses across multiple AMD Ryzen processor families (6000, 7000, 8000 series). This CWE-252 flaw enables privilege escalation to kernel level, compromising system confidentiality and availability with high impact across both virtualized and physical contexts. AMD has released security bulletin AMD-SB-4015 addressing the vulnerability. No CISA KEV listing or public exploit code has been identified at time of analysis, but the low attack complexity (AC:L) and local privilege requirement (PR:L) suggest exploitation is technically straightforward for attackers with initial system access.

Local privilege escalation in AMD Platform Management Framework (PMF) allows authenticated attackers with low privileges to unmap arbitrary memory pages, potentially executing code with elevated privileges or triggering system crashes. Affects modern AMD Ryzen mobile processors across multiple generations (6000/7000/8000/AI 300 series, embedded variants). The vulnerability enables both horizontal escalation (confidentiality compromise via changed scope in CVSS 4.0) and vertical impact (integrity/availability degradation). No evidence of active exploitation (not in CISA KEV), but the local attack vector with low complexity makes this exploitable by malware or malicious insiders once system access is obtained. EPSS data not available for risk calibration.

Uninitialized kernel memory within AMD's Platform Management Framework (PMF) can be read by local authenticated attackers, resulting in information disclosure or availability impact. This affects AMD Ryzen processors across multiple generations (6000, 7035, 7040, 8040 series and Z1/Embedded 8000) where PMF is present. The vulnerability requires local access and authenticated user privileges but does not require user interaction, making it exploitable by any local user with login credentials.

Out-of-bounds write in the AMD Platform Management Framework (PMF) Driver enables local authenticated users to escalate privileges on AMD Ryzen 6000/7000/8000 series processors. The vulnerability stems from improper input validation (CWE-787) allowing memory corruption beyond allocated buffer boundaries. Exploitation requires low-privilege local access with low attack complexity (CVSS 4.0: AV:L/AC:L/PR:L), making this a realistic post-compromise escalation vector. AMD released chipset driver version 7.06.02.123 addressing all affected Ryzen series. No public exploit or active exploitation confirmed at time of analysis.

Improper input validation in the AMD Platform Management Framework (PMF) driver allows local authenticated attackers to read out-of-bounds memory, resulting in information disclosure or denial of service. The vulnerability affects multiple Ryzen processor families (7035, 7040, 8040, 6000 series, and Embedded 8000) and requires local access with limited privileges to exploit.

Out-of-bounds read/write in AMD Platform Management Framework (PMF) driver allows local authenticated users to escalate privileges on Ryzen 6000/7000/8000 series processors. AMD has released patched chipset software version 7.06.02.123 addressing the improper input validation vulnerability. No public exploit code identified and CISA has not added this to KEV, indicating exploitation is not yet confirmed in real-world attacks despite the high CVSS score. Attackers must already have local system access with standard user privileges to exploit this vulnerability.

Buffer overflow in the AMD Secure Processor (ASP) PCI driver affects dozens of AMD Ryzen, EPYC, and Threadripper processor families across desktop, mobile, and embedded variants. Local attackers with user-level privileges can trigger improper input validation in the driver to cause a crash or denial of service, with potential for integrity impact. The vulnerability requires local access and authenticated user privileges; no active exploitation in the wild has been confirmed, and vendor-released patches are available.

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.

Use-After-Free vulnerability in the AMD Secure Processor (ASP) PCI driver affects multiple Ryzen, Threadripper, EPYC, and Athlon processor families due to improper input validation. A local attacker with user-level privileges can trigger the UAF condition, resulting in denial of service via platform crash or potential loss of platform integrity. Vendor-released patch: AMD Ryzen Chipset Driver 7.02.13.148 (or equivalent Catalyst driver versions for embedded SKUs). No public exploit identified at time of analysis.

Privilege escalation in AMD GPIO controller driver for Windows allows authenticated local users with low privileges to execute arbitrary code with elevated rights via insecure directory permissions. Affects nearly the entire AMD processor portfolio from Ryzen 3000-series through latest EPYC 9005 and Ryzen AI 300. AMD has released patched chipset drivers (version 7.04.09.545 for most desktop/mobile products, 8.03.16.641 for server platforms) addressing the vulnerability. EPSS score and KEV status not provided in source data, but the local attack vector and user interaction requirement limit remote exploitation risk despite the 7.0 CVSS score.

Improper input validation in the AMD OverDrive (AOD) System Management Mode (SMM) module could allow a privileged attacker to perform an out-of-bounds read, potentially resulting in loss of. Rated medium severity (CVSS 4.6), this vulnerability is low attack complexity. No vendor patch available.

Arbitrary code execution in AMD optional tools occurs through DLL injection during unsafe OpenSSL initialization, allowing local authenticated attackers with low-privilege user access and user interaction to execute malicious code with high impact to confidentiality, integrity, and availability. The vulnerability stems from insecure library loading (CWE-427) where the affected AMD utilities fail to validate DLL search paths during OpenSSL library initialization. No active exploitation confirmed (not in CISA KEV) and no public exploit code identified at time of analysis, though the low attack complexity (AC:L) indicates straightforward exploitation once local access is obtained.

Null pointer dereference in the Linux kernel's AMD ASoC ACP3x audio driver (acp3x-rt5682-max9836) allows a local low-privileged user on affected hardware to crash the kernel. The flaw originates in acp3x_5682_init(), which failed to validate the return value of clk_get() before passing it to rt5682_clk_enable(), meaning an error pointer could be dereferenced directly. No public exploit identified at time of analysis and the EPSS score of 0.02% (7th percentile) reflects extremely low exploitation interest; this vulnerability is not listed in the CISA KEV catalog.

Privilege escalation into the AMD Secure Processor affects AMD EPYC 8004/9004/9005 and EPYC Embedded 8004/9004/9005 series processors, where missing lock bit protection on NBIO registers lets a local admin-privileged attacker gain arbitrary System Management Network (SMN) access. This can lead to arbitrary code execution inside the AMD Secure Processor (ASP) and breaks the confidentiality and integrity guarantees SEV-SNP is supposed to provide to confidential-computing guests. There is no public exploit identified at time of analysis, EPSS risk is negligible (0.01%), and CISA SSVC rates exploitation as none but technical impact as total.

Null pointer dereference in the Linux kernel's ASoC AMD ACP machine-common driver can be triggered by a local authenticated user to crash the kernel, resulting in a denial of service. The functions acp_card_rt5682_init() and acp_card_rt5682s_init() in sound/soc/amd/acp/acp-mach-common.c fail to validate the return value of clk_get(), allowing an invalid error pointer to be dereferenced by downstream clock core functions. No public exploit code exists and no active exploitation has been confirmed; EPSS probability stands at 0.02% (5th percentile), reflecting very low real-world exploitation likelihood.

Memory leak and denial-of-service in the Linux kernel macb network driver (used in AMD ZynqMP platforms) allows local authenticated users to cause prolonged network disruption and system resource exhaustion. The flaw manifests during suspend/resume cycles when the transmit ring pointer resets incorrectly, silently dropping queued packets without releasing their memory, and causing the driver to become stuck waiting for already-transmitted packets. Real-world impact observed in NFS rootfs recovery delays. EPSS score of 0.02% (7th percentile) indicates low exploitation likelihood. Vendor patches available across multiple stable kernel branches (6.1.167, 6.6.130, 6.12.78, 6.18.20, 6.19.9).

A NULL pointer dereference in Linux kernel AMD GPU driver cleanup code causes local denial of service when GPU initialization fails on systems with unsupported AMD hardware blocks. Local authenticated users with low privileges can trigger kernel crashes during device teardown sequences. The vulnerability affects multiple stable kernel versions (6.18.16-6.18.19, 6.19.6-6.19.9) with patches available from upstream. EPSS score of 0.02% (4th percentile) indicates very low observed exploitation probability, and no active exploitation or public exploits are confirmed. Real-world impact is limited to systems with specific AMD GPU hardware experiencing initialization failures, making this primarily a reliability issue rather than a direct security threat.