CVE-2026-63856

What it actually does

This is a local privilege-escalation flaw in the Linux kernel AMDGPU DRM driver affecting VCN v2.0 video encode/decode rings. Those rings do not support 64-bit user-fence writes, but the vulnerable driver path did not reject command submissions that requested user fences. A local user with permission to submit GPU command streams through the DRM device interface could provide crafted command submission parameters that exercise unsupported fence handling, potentially causing incorrect kernel/GPU memory writes, driver corruption, system instability, or elevation of privileges in the kernel context. The CVSS vector indicates local access, low attack complexity, low privileges required, no user interaction, and high confidentiality, integrity, and availability impact.

Why it matters to the business

Systems that expose AMDGPU DRM devices to local users, desktop sessions, containers with GPU passthrough, media workloads, VDI, or GPU-accelerated compute environments may allow a low-privileged user or compromised local process to gain control of the host. Operational consequences include host compromise, data theft, tampering, service disruption from kernel crashes or GPU resets, and loss of isolation between users or workloads sharing the same Linux host. EPSS is currently very low and there is no known KEV listing or ransomware association, but the vulnerability is recent and should still be prioritized where untrusted users or workloads can access AMD GPU devices.

How an attack unfolds

An attacker first obtains low-privileged local code execution on a Linux system using the vulnerable AMDGPU driver and with access to DRM GPU device nodes such as render or card devices. The attacker then opens the AMDGPU DRM interface and submits a crafted command stream targeting VCN v2.0 encode/decode rings while requesting a user fence operation those rings do not support. Because the vulnerable driver does not reject this combination, the command submission can trigger unsafe or undefined fence handling in the GPU driver path. A reliable exploit would shape the command stream and memory layout to turn the faulty fence behavior into kernel memory corruption or another privileged state change, then use that condition to escalate privileges, disable security controls, or crash the system. Exploitation requires local access and applicable AMDGPU hardware/driver support; there is no indication of public exploit maturity or active exploitation at this time.

How to fix it

Upgrade to a Linux kernel or vendor kernel package that includes the AMDGPU fix which marks VCN v2.0 encoder and decoder rings as not supporting user fences and rejects command submissions using user fences for those rings. The upstream fix is associated with commit e2b5499fca55f1a32960a311bbb62e35891eaf73, but organizations should use distribution-supported kernel updates rather than manually patching production kernels unless they maintain custom kernels. Because no fixed package versions were provided in the input, consult the relevant Linux distribution, appliance, cloud image, or kernel vendor advisory for the exact fixed release. Where immediate patching is not possible, reduce exposure by limiting access to /dev/dri/card* and /dev/dri/renderD* to trusted users only, removing unnecessary GPU passthrough from containers or virtual machines, disabling GPU access for untrusted workloads, or unloading/blacklisting the amdgpu module on systems that do not require AMD GPU functionality. These mitigations may affect graphics, video encoding/decoding, remote desktop, and GPU-accelerated workloads and should be tested before broad deployment.

How to confirm the fix worked

Confirm the running kernel is updated to a vendor release that contains the AMDGPU VCN user-fence rejection fix. For source-built kernels, verify that the relevant AMDGPU VCN ring initialization sets the no_user_fence behavior for VCN v2.0 encode/decode rings or includes the upstream fix commit. Validate that all exposed hosts have rebooted into the fixed kernel, because merely installing a kernel package is insufficient if the old kernel is still running. Check whether AMDGPU is loaded with commands such as lsmod, modinfo, or distribution inventory tooling, and identify exposed DRM nodes under /dev/dri/. Validate permissions on DRM device nodes and group membership so only intended users or services can submit GPU command streams. In containerized or virtualized environments, confirm that GPU devices are not passed through to untrusted workloads unless the host kernel is fixed.

Typical attack path

1. Gain low-privileged local execution on a Linux host, for example through an existing account, compromised service, desktop session, container escape precondition, or malware already running locally.
2. Confirm the host uses the AMDGPU kernel driver and exposes DRM device nodes to the attacker-controlled user or workload.
3. Open the DRM render or card device and prepare GPU-accessible memory buffers and command submission structures.
4. Submit a crafted command stream to VCN v2.0 encoder or decoder rings with user-fence parameters that should have been rejected.
5. Trigger unsupported fence handling in the vulnerable AMDGPU driver path.
6. Leverage the resulting corruption, fault, or privileged side effect to escalate privileges, alter kernel-controlled data, or cause a denial of service.
7. Use elevated privileges to persist, access sensitive data, tamper with workloads, or move laterally from the compromised host.

How to detect it

There are no unique public exploitation indicators for this issue in the provided data, and successful local kernel exploitation may leave few definitive artifacts. To assess possible prior exploitation, review kernel logs and persistent system journals for AMDGPU faults, VCN ring errors, GPU hangs, ring resets, kernel oops messages, general protection faults, or crashes occurring shortly before suspicious privilege changes. Review auditd, eBPF, EDR, or process accounting telemetry for unexpected local processes opening /dev/dri/card* or /dev/dri/renderD* and submitting ioctl-heavy workloads, especially from temporary directories, user-writable paths, containers, or accounts that do not normally use GPU acceleration. Correlate suspicious DRM device access with new setuid binaries, unauthorized sudoers changes, unexpected kernel module activity, new persistence mechanisms, abnormal container escapes, or sudden changes in user privileges. On container hosts, inspect workloads that were granted GPU device passthrough and look for processes with unusual access to DRM device nodes. Treat crashes alone as weak signals because legitimate driver instability can produce similar logs; stronger suspicion comes from GPU/AMDGPU faults closely followed by privilege escalation, persistence, or lateral movement artifacts.

What your security team should do

• Inventory Linux systems using AMDGPU, especially desktops, VDI hosts, media transcoding servers, GPU compute nodes, and container platforms with /dev/dri device passthrough.
• Prioritize patching systems where multiple users, untrusted workloads, or containers can access AMD GPU DRM devices.
• Deploy the vendor-supported fixed kernel and reboot affected systems into the new kernel; verify the running kernel version after maintenance.
• Temporarily restrict permissions to /dev/dri/card* and /dev/dri/renderD* or remove GPU passthrough for untrusted workloads until patching is complete.
• Review local user, service, and container access to video/render groups and remove unnecessary membership.
• Enable or review audit logging for access to DRM device nodes on high-risk multi-user systems.
• Monitor for kernel oops, GPU hangs, amdgpu ring reset messages, unexplained privilege changes, and suspicious local processes interacting with DRM devices.
• Because there is no KEV listing, no ransomware association, and very low EPSS at this time, treat this as important for exposed multi-user/GPU-shared systems rather than an internet-wide emergency.