CVE-2026-63855

What it actually does

This is a Linux kernel AMDGPU driver flaw in the VCN v2.5 video encode/decode command submission path. VCN encoder and decoder rings do not support 64-bit user fence writes, but vulnerable kernels could accept command submissions that included user fences for those rings. A local user with access to the AMD GPU device nodes could submit malformed GPU command streams through the DRM/AMDGPU interface, potentially causing invalid memory writes, kernel memory corruption, GPU hangs, or privilege escalation. The fix marks the affected VCN rings with no_user_fence so command submissions using user fences are rejected before reaching unsupported hardware paths.

Why it matters to the business

Successful exploitation could allow a local, low-privileged user or workload with GPU access to compromise the underlying Linux host, disrupt graphics/video workloads, or cause denial of service through GPU or kernel instability. The risk is highest on multi-user Linux systems, VDI hosts, media transcoding servers, shared build/compute systems, and container platforms that pass AMD GPU devices into workloads. This issue is not currently listed in CISA KEV, has no known mature public exploit, and has a low EPSS score, but the CVSS impact is high because exploitation occurs in kernel driver context.

How an attack unfolds

An attacker first obtains local code execution on a Linux system where the amdgpu kernel driver is loaded and the attacker can open DRM device nodes such as render or card devices. They identify an AMD GPU using VCN v2.5 encode/decode rings and construct an AMDGPU command submission targeting those rings. The malicious submission includes a 64-bit user fence even though the hardware path does not support that operation. On vulnerable kernels, the driver does not reject this invalid combination early enough, allowing the request to reach unsafe driver or hardware handling paths. Depending on system state and exploit reliability, this may trigger GPU reset, kernel crash, memory corruption, or controlled corruption that can be developed into local privilege escalation. Patched kernels reject these command submissions by marking the VCN v2.5 encoder/decoder rings as not supporting user fences.

How to fix it

Update to a Linux kernel version from the distribution or vendor that includes the AMDGPU fix for VCN v2.5 encode/decode rings, specifically the change that sets no_user_fence for those rings and rejects command submissions using user fences. Where exact fixed package versions are not available, track the vendor kernel advisory for CVE-2026-63855 or confirm inclusion of upstream commit efc9dd5590894109bce9a0bfe1fa5592dd6b20b1 or its backport. Reboot after installing the kernel so the patched amdgpu module is loaded. As temporary mitigation, restrict local access to /dev/dri/card* and /dev/dri/renderD* to only trusted users and workloads, avoid passing AMD GPU devices into untrusted containers or VMs, and disable or remove AMDGPU access on systems that do not require hardware video acceleration.

How to confirm the fix worked

Confirm the running kernel, not just the installed package, is updated after reboot. Verify that the vendor kernel changelog or source package includes the AMDGPU VCN no_user_fence fix or a backport of commit efc9dd5590894109bce9a0bfe1fa5592dd6b20b1. On exposed hosts, confirm the amdgpu module is loaded only where required and review permissions on /dev/dri/card* and /dev/dri/renderD* to ensure GPU access is limited. Functional validation can be performed in a test environment by submitting or fuzzing AMDGPU command submissions with user fences against VCN encode/decode rings and confirming the patched kernel rejects them rather than hanging, resetting the GPU, or crashing. Review dmesg/journal logs after validation for absence of GPU faults, kernel oopses, or amdgpu reset storms.

Typical attack path

1. Gain local code execution as an unprivileged user, service account, container workload, or desktop user.
2. Confirm access to AMDGPU DRM device nodes such as /dev/dri/renderD* or /dev/dri/card*.
3. Identify an AMD GPU/driver configuration exposing VCN v2.5 encode or decode rings.
4. Open the DRM/AMDGPU interface and prepare a command submission for the VCN encode/decode ring.
5. Include an unsupported 64-bit user fence in the command submission.
6. Submit the crafted workload through the AMDGPU command submission ioctl path.
7. Abuse the resulting invalid write, memory corruption, GPU hang, or kernel fault to cause denial of service or attempt privilege escalation.

How to detect it

Because exploitation is local and may occur through normal DRM/AMDGPU device interfaces, there may be no clean network indicator. Review host telemetry and kernel logs for suspicious AMDGPU command submission failures, repeated GPU resets, VCN ring faults, kernel oopses, page faults, or crashes involving the amdgpu driver. Useful log sources include dmesg, journald/kern.log, auditd records for access to /dev/dri/card* and /dev/dri/renderD*, EDR process telemetry, container runtime device-mount logs, and crash dump/kdump artifacts. Focus on systems where untrusted users or containers had access to AMD GPU device nodes shortly before amdgpu faults, GPU resets, or kernel instability. Investigate processes repeatedly opening DRM render nodes and then triggering amdgpu ring timeouts, VCN errors, or kernel faults. There are no public threat actors or ransomware campaigns currently associated with this issue.

• /dev/dri/renderD
• /dev/dri/card
• amdgpu
• VCN
• user fence
• ring vcn
• GPU reset
• ring timeout
• amdgpu: GPU fault
• amdgpu: ring
• amdgpu: failed
• amdgpu: reset
• DRM_IOCTL_AMDGPU_CS

What your security team should do

• Prioritize patching multi-user Linux systems, GPU-enabled container hosts, VDI/desktop fleets, media transcoding servers, and shared compute hosts with AMD GPUs.
• Inventory Linux systems with the amdgpu driver loaded and exposed /dev/dri devices, especially systems allowing non-admin users or containers to access render nodes.
• Apply vendor kernel updates and reboot to load the patched kernel/module.
• Until patched, remove untrusted users from GPU-access groups such as video or render where operationally feasible.
• Avoid passing /dev/dri devices into untrusted containers or sandboxed workloads unless strictly required.
• Monitor kernel logs for amdgpu faults, GPU resets, command submission failures, and kernel oops/panic events.
• Treat suspicious GPU-related crashes or resets on shared systems as potential local exploitation attempts and preserve kernel logs for investigation.