CVE-2026-63854

What it actually does

This is a local Linux kernel amdgpu driver input-validation flaw in the VCN 3.0 video encode/decode command submission path. The vulnerable driver accepts command submissions that include user fences even though the VCN encoder and decoder rings do not support 64-bit user-fence writes. A local user with permission to submit GPU work through the DRM/amdgpu device interface could supply an invalid command stream that causes unsafe driver/GPU behavior, potentially leading to kernel memory corruption, privilege escalation, information disclosure, or denial of service. The CVSS vector indicates local access is required, privileges are required, no user interaction is needed, and successful exploitation can affect confidentiality, integrity, and availability.

Why it matters to the business

Systems using affected Linux kernels with AMD GPUs may be exposed to local privilege escalation or system instability from an otherwise low-privileged account, container, desktop session, or GPU-enabled workload. In multi-user workstations, VDI, CI/build hosts, media-processing nodes, and GPU-sharing environments, this can turn limited local access into full host compromise or disruptive kernel crashes. The vulnerability is not currently listed in CISA KEV, has low EPSS, and has no known public exploit maturity, but kernel privilege-escalation bugs should still be prioritized where untrusted users or workloads can access AMD GPU devices.

How an attack unfolds

An attacker first obtains local code execution with access to the Linux DRM/amdgpu device nodes, such as through a shell account, compromised application, container with GPU passthrough, or desktop session. They then craft a DRM command submission targeting the AMD VCN 3.0 encoder or decoder rings and include a user fence that the hardware ring does not correctly support. On vulnerable kernels, the driver fails to reject this unsupported fence configuration before submission. The malformed GPU work can trigger unsafe behavior in the amdgpu kernel driver or GPU execution path, potentially corrupting kernel-managed state, leaking memory, escalating privileges, or crashing/resetting the system. Fixed kernels reject such command submissions before they reach the unsupported VCN rings.

How to fix it

Upgrade to a Linux kernel build that includes the amdgpu fix which sets no_user_fence for VCN v3.0 encoder and decoder rings and rejects command submissions containing user fences for those rings. If using a distribution kernel, apply the vendor security update for the affected kernel package rather than relying only on upstream version numbers. If an immediate kernel update is not possible, reduce exposure by restricting access to AMD GPU DRM device nodes, removing untrusted users from GPU-access groups such as video or render, disabling GPU passthrough for untrusted containers or virtual machines, and avoiding shared GPU workloads from untrusted tenants. Where feasible, temporarily unload or blacklist the amdgpu driver on systems that do not require AMD GPU acceleration, recognizing this may affect graphics or compute functionality.

How to confirm the fix worked

Confirm the running kernel includes the vendor fix for the amdgpu VCN user-fence rejection behavior. Validate by checking distribution security advisories and installed kernel package changelogs for the CVE or the amdgpu change that sets no_user_fence for VCN v3.0 encode/decode rings. After patching, reboot into the updated kernel and verify with uname -a and package-manager inventory that the fixed kernel is active, not merely installed. Confirm that untrusted users and workloads cannot access /dev/dri/card* or /dev/dri/renderD* unless required. For exposure testing, inventory systems with AMD GPUs and loaded amdgpu modules using lspci, lsmod, and /dev/dri presence; vulnerable exposure generally requires local users or workloads with access to those device nodes.

Typical attack path

1. Gain local execution on a Linux system that has an affected AMD GPU and the amdgpu kernel driver loaded.
2. Confirm access to DRM render or card device nodes, commonly under /dev/dri/.
3. Open the DRM/amdgpu device and construct a command submission for VCN 3.0 encode or decode rings.
4. Attach a user fence to the command submission even though those rings do not support the required 64-bit user-fence writes.
5. Submit the malformed command stream to trigger vulnerable kernel-driver behavior.
6. Use the resulting memory corruption or fault condition to attempt privilege escalation, information disclosure, or system denial of service.

How to detect it

There are no reliable remote network indicators for this local kernel-driver issue. To assess possible prior exploitation, review kernel logs, system journals, audit logs, and endpoint telemetry for amdgpu/DRM activity followed by GPU resets, kernel oops/panic events, privilege changes, or suspicious local process execution. Useful sources include journalctl/kern.log/dmesg, auditd records for access to /dev/dri/card* and /dev/dri/renderD*, EDR process telemetry, sudo/su authentication logs, and container runtime logs showing GPU device mounts. Focus on events where untrusted users or containers accessed DRM device nodes shortly before amdgpu VCN ring faults, GPU resets, or kernel crashes. If auditd was enabled, search for open/read/write/ioctl activity against DRM device nodes by unexpected users or workloads. Absence of these artifacts does not prove non-exploitation because successful local kernel exploitation may leave minimal logs.

• /dev/dri/renderD
• /dev/dri/card
• amdgpu
• VCN
• vcn_dec
• vcn_enc
• user fence
• no_user_fence
• ring vcn
• amdgpu: ring vcn
• drm:amdgpu_job_timedout
• GPU reset
• amdgpu_device_gpu_recover
• kernel BUG at drivers/gpu/drm/amd/amdgpu
• BUG: kernel NULL pointer dereference
• general protection fault
• Oops:
• Kernel panic
• audit: PATH item=0 name="/dev/dri/renderD
• audit: PATH item=0 name="/dev/dri/card

What your security team should do

• Prioritize patching Linux systems with AMD GPUs that allow shared, untrusted, or semi-trusted local access, including GPU-enabled containers, VDI, media-processing hosts, build systems, and research workstations.
• Deploy the relevant distribution kernel security update and reboot systems to ensure the fixed kernel is running.
• Restrict /dev/dri/card* and /dev/dri/renderD* access to only trusted users and services until patching is complete.
• Review container, VM, and orchestration policies for GPU passthrough or device mounts that expose AMD GPU devices to untrusted workloads.
• Monitor kernel, audit, and system logs for amdgpu crashes, VCN ring errors, GPU resets, and suspicious access to DRM device nodes.
• Treat unexplained kernel oops, panic, or amdgpu reset events on shared GPU systems as potential local exploitation until ruled out.
• Because this is not currently in KEV and has low EPSS with no known public exploit, schedule broadly but escalate urgency for internet-facing services that lead to local code execution or environments with untrusted local users.