CVE-2026-53375

What it actually does

This is a Linux kernel memory-corruption vulnerability in the AMDGPU VCE driver path. When video codec engine address patching receives only one valid half of an address pair, the driver can construct and submit an invalid or partially patched address to firmware. Because this occurs in kernel/GPU driver handling, a local user with access to the affected GPU interface may be able to trigger corruption that impacts kernel memory, GPU firmware behavior, or system stability. The CVSS vector indicates local access is required, low attack complexity, low privileges, no user interaction, and potential confidentiality, integrity, and availability impact across a changed scope.

Why it matters to the business

Successful exploitation could allow a local attacker or compromised low-privileged process on a Linux system using affected AMDGPU functionality to crash systems, corrupt workloads, or potentially escalate impact beyond the original process. This is most relevant for workstations, GPU-enabled servers, rendering systems, VDI hosts, media-processing nodes, and multi-user Linux environments where untrusted or semi-trusted users can access GPU devices. The issue is not known to be exploited in the wild, is not listed in CISA KEV, and currently has low EPSS probability, but the high CVSS impact means it should still be addressed through normal kernel update cycles, especially on shared or GPU-exposed systems.

How an attack unfolds

An attacker first needs local code execution with sufficient permission to interact with the AMDGPU device interface, such as through normal user access to a GPU-enabled Linux host or through a compromised low-privileged application. The attacker then exercises the video codec engine path in a way that causes address patching to proceed when only one of the low or high address components is valid. This can result in a malformed address being written to or consumed by firmware. Depending on kernel version, driver state, hardware behavior, and memory layout, the result may be a kernel crash, GPU hang, data corruption, information exposure, or a path toward broader privilege impact. There is no public indication in the provided intelligence that weaponized exploit code or named threat actor exploitation currently exists.

How to fix it

Apply a Linux kernel update that includes the upstream AMDGPU VCE fix for preventing partial address patches. Because no specific affected product list or fixed package versions were provided, remediation should be performed through the relevant Linux distribution or kernel vendor update channel and verified against vendor advisories for this CVE. Prioritize GPU-enabled multi-user systems and systems that allow containers, desktop sessions, rendering jobs, media processing, or untrusted workloads to access AMDGPU devices. Where immediate patching is not possible, reduce exposure by restricting access to GPU device nodes, limiting membership in groups that can access DRM/render devices, disabling or avoiding VCE-dependent workloads where feasible, isolating untrusted GPU workloads, and applying least-privilege controls around local shell, container, and desktop access.

How to confirm the fix worked

Confirm the running kernel version contains the vendor backport or upstream fix for the AMDGPU VCE partial address patching issue. Validate both the installed kernel package and the actively running kernel after reboot. On Linux systems, compare `uname -r` and package-manager output against the distribution advisory, and confirm the system has rebooted into the fixed kernel. Review whether AMDGPU is in use by checking loaded modules and hardware presence, for example `lsmod | grep amdgpu`, `lspci | grep -i amd`, and `/sys/class/drm/`. Validate mitigation by confirming nonessential users and workloads cannot access `/dev/dri/card*` or `/dev/dri/renderD*` unless required. Functional testing should include representative GPU/video workloads after patching to ensure driver stability.

Typical attack path

1. Gain local low-privileged execution on a Linux system using the AMDGPU driver and VCE functionality.
2. Confirm access to GPU device nodes or APIs that reach the vulnerable AMDGPU VCE code path.
3. Trigger video codec engine operations that cause only one half of an address pair to be considered valid during patching.
4. Cause the driver or firmware to operate on a malformed address.
5. Leverage the resulting memory corruption or device fault to crash the host, disrupt GPU workloads, corrupt memory, or attempt further privilege-impacting exploitation.

How to detect it

Detection should focus on evidence of attempted local exploitation or instability in the AMDGPU driver rather than network indicators, because exploitation requires local access and no specific public exploit artifacts are provided. Review kernel logs, system journals, crash dumps, and GPU driver telemetry for AMDGPU/VCE faults, GPU resets, malformed memory access symptoms, kernel oops messages, page faults, general protection faults, IOMMU faults, or repeated GPU hangs. Useful log sources include `journalctl -k`, `/var/log/kern.log`, `/var/log/messages`, `/var/log/syslog`, `dmesg`, crash dump repositories such as `/var/crash/`, kdump/vmcore artifacts, audit logs for access to `/dev/dri/*`, and EDR telemetry for local processes opening DRM/render device nodes shortly before a crash. Correlate suspicious events with user sessions, container launches, rendering/media workloads, or unusual binaries invoking GPU APIs. Absence of these indicators does not prove non-exploitation, because a reliable exploit may leave only generic kernel or GPU fault artifacts.

• amdgpu
• amdgpu: GPU reset
• amdgpu: ring vce
• amdgpu: VCE
• VCE
• GPU fault detected
• GPU reset begin
• GPU reset succeeded
• GPU reset failed
• ring vce timeout
• ring vce0 timeout
• ring vce1 timeout
• ring vce2 timeout
• drm:amdgpu_job_timedout
• amdgpu_job_timedout
• amdgpu_device_gpu_recover
• amdgpu_vce
• BUG: kernel NULL pointer dereference
• BUG: unable to handle page fault
• general protection fault
• kernel BUG at
• Oops:
• IOMMU fault
• /dev/dri/card0
• /dev/dri/renderD128
• /var/crash/
• vmcore

What your security team should do

• Inventory Linux systems with AMD GPUs and the `amdgpu` kernel driver loaded, prioritizing shared workstations, GPU compute nodes, VDI, rendering, and media-processing hosts.
• Patch affected systems through the OS or kernel vendor channel and reboot into the fixed kernel.
• Restrict local access to GPU device nodes to only users, services, and containers that require it.
• Review container, VDI, and batch-processing configurations for unnecessary GPU passthrough or broad `/dev/dri` exposure.
• Monitor for kernel GPU faults, AMDGPU resets, general protection faults, and unexplained host crashes that could indicate attempted triggering.
• Because exploitation is not currently reported in KEV and EPSS is low, handle as a high-impact local vulnerability rather than an internet-scale emergency unless the environment exposes GPU access to untrusted users.