CVE-2026-63853

What it actually does

This is a local Linux kernel vulnerability in the AMDGPU DRM driver’s VCN 4.0 video encode/decode command submission path. The vulnerable code accepted command submissions that requested user-fence writes even though the affected VCN rings do not support 64-bit user-fence operations. A local user with access to the GPU device node could submit a crafted DRM command stream that causes the kernel/GPU driver to process an unsupported fence operation, potentially leading to memory corruption, privilege escalation, information disclosure, or a system crash depending on hardware, kernel configuration, and driver state.

Why it matters to the business

Systems using affected Linux kernels with AMD GPUs may allow a local, low-privileged user or compromised application to escalate privileges or disrupt the host. The main business risk is that compromise of an unprivileged workload, desktop session, container with GPU access, or media-processing service could become full host compromise. Because this requires local access and there is no known public exploit or CISA KEV listing, internet-wide urgency is lower than for remotely exploitable flaws, but GPU-enabled shared workstations, CI runners, VDI hosts, render nodes, and multi-tenant compute platforms should prioritize remediation.

How an attack unfolds

An attacker first obtains local code execution as an unprivileged user on a Linux system that exposes AMDGPU DRM device access, typically through /dev/dri/card* or /dev/dri/renderD*. The attacker then opens the DRM device and submits a crafted AMDGPU command stream targeting a VCN 4.0 encoder or decoder ring while requesting a user fence. On vulnerable kernels, the driver does not reject this unsupported operation before submission. The GPU/driver may then attempt to handle a fence write in a way the VCN ring does not support, creating an unsafe kernel/GPU memory interaction. Successful exploitation could result in kernel memory corruption, privilege escalation, disclosure of sensitive memory, or denial of service through GPU reset or kernel crash. The fix changes the driver behavior so VCN encoder/decoder rings reject command submissions that include user fences.

How to fix it

Upgrade to a Linux kernel version that includes the AMDGPU fix which marks the affected VCN encoder/decoder rings as not supporting user fences and rejects such command submissions. If vendor packages are used, apply the latest security kernel update from the Linux distribution, appliance vendor, or cloud image provider. If maintaining a custom kernel, ensure the fix corresponding to upstream commit fd852c048b46f9825e904a4f3f4538fe9d8827d9, or its equivalent backport, is present. Where immediate patching is not possible, reduce exposure by limiting local GPU device access, removing untrusted users from render/video groups, restricting /dev/dri access in containers, disabling GPU passthrough for untrusted workloads, or temporarily unloading/blacklisting the amdgpu module on systems that do not require the affected GPU functionality.

How to confirm the fix worked

Confirm remediation by verifying the running kernel package includes the vendor security update or the relevant upstream/backported AMDGPU patch. On source-based or custom kernels, inspect the AMDGPU VCN ring initialization code and confirm VCN encoder/decoder rings set the no_user_fence behavior so command submissions with user fences are rejected. Validate exposure by checking whether the amdgpu kernel module is loaded, whether AMD GPU DRM devices exist under /dev/dri, and whether untrusted users or containers have access to those devices. After patching, perform a controlled reboot if required by the kernel update, confirm the new kernel is running with uname -a or package tooling, and review dmesg/journalctl for AMDGPU initialization without repeated VCN ring faults or GPU resets.

Typical attack path

1. Gain local code execution on a Linux host with an AMD GPU and AMDGPU driver loaded.
2. Confirm access to GPU DRM device nodes such as /dev/dri/renderD* or /dev/dri/card*.
3. Identify that the system is using affected AMDGPU VCN 4.0 hardware and a vulnerable kernel build.
4. Open the DRM device and issue crafted AMDGPU command submissions to a VCN encoder or decoder ring.
5. Include a user-fence request that the vulnerable driver fails to reject.
6. Trigger unsafe GPU/driver behavior, potentially causing memory corruption, privilege escalation, information disclosure, or a system crash.
7. If exploitation succeeds, use elevated privileges or recovered data to persist, move laterally, or disable defenses.

How to detect it

Detection of prior exploitation is difficult because successful attempts may look like GPU instability, kernel faults, or abnormal DRM command submissions rather than a clear application-layer signature. Review journalctl, dmesg, kern.log, syslog, auditd, and EDR telemetry for AMDGPU errors involving VCN encoder/decoder rings, GPU faults, ring timeouts, GPU resets, kernel oops/panic events, or unusual processes repeatedly opening /dev/dri devices before a crash or privilege change. On multi-user systems, correlate AMDGPU faults with audit events showing access to /dev/dri/renderD* or /dev/dri/card* by non-administrative users, containers, media-processing jobs, browsers, or unknown binaries. If auditd or eBPF telemetry is available, search for suspicious ioctl-heavy activity against DRM device nodes followed by amdgpu ring reset messages, process crashes, new privileged processes, or unexpected changes to user/group membership. There are no known public exploit-specific payload strings, file hashes, domains, or named threat actors for this vulnerability at this time.

• amdgpu: GPU fault detected
• amdgpu: GPU reset begin
• amdgpu: GPU reset succeeded
• amdgpu: ring vcn_enc
• amdgpu: ring vcn_dec
• amdgpu: ring vcn_enc timeout
• amdgpu: ring vcn_dec timeout
• amdgpu: VCN
• drm:amdgpu_cs_ioctl
• /dev/dri/renderD
• /dev/dri/card
• amdgpu_job_timedout
• amdgpu_device_gpu_recover
• kernel: amdgpu

What your security team should do

• Prioritize patching Linux systems with AMD GPUs that are shared, multi-user, internet-facing through hosted workloads, used for VDI, CI/CD, rendering, media processing, AI/ML, or containers with GPU access.
• Inventory hosts where the amdgpu module is loaded and /dev/dri devices are accessible to non-administrative users or containers.
• Apply distribution or vendor kernel security updates and reboot into the fixed kernel; for custom kernels, confirm the specific AMDGPU VCN user-fence rejection fix is included.
• Until patched, restrict membership in groups that grant DRM/GPU access, commonly render or video, and prevent untrusted containers from mounting /dev/dri devices.
• Monitor kernel logs for AMDGPU VCN ring faults, GPU resets, page faults, and suspicious DRM command-submission activity from untrusted processes.
• Treat unexplained GPU resets or kernel crashes on shared AMD GPU systems as potentially security-relevant until patched and investigated.
• Because EPSS is low and there is no known KEV or public exploit maturity, use risk-based prioritization, but do not defer remediation on systems where local users are untrusted.