CVE-2026-68107

What it actually does

This is a race condition in the Linux kernel AMDGPU VCN 4 video encode command-buffer handling. The vulnerable code reads an indirect buffer parameter length, validates or locates the parameter, and then may read the length again later; if the buffer contents change between those reads, the driver can operate on inconsistent metadata. In practice, a local user with access to AMDGPU DRM device nodes may be able to trigger incorrect bounds handling in kernel driver code, leading to GPU driver crashes, kernel faults, denial of service, or potentially kernel memory corruption depending on surrounding kernel version, hardware, and exploit reliability.

Why it matters to the business

Systems using affected Linux kernels with AMD GPUs may be exposed to local attacks that can crash GPU workloads or the host, disrupt desktop, rendering, media, AI, or compute services, and potentially increase the impact of a compromised low-privileged account. This issue is not currently listed in CISA KEV, is not known to be used in ransomware campaigns, and has no public exploit maturity reported, but it was recently published and should be remediated through normal kernel update processes, especially on shared workstations, GPU compute hosts, and container platforms that expose /dev/dri devices to untrusted users.

How an attack unfolds

An attacker first needs local code execution or the ability to run a workload with access to the AMDGPU DRM render or card device. They open the GPU device and submit a crafted VCN 4 video encode indirect buffer through normal DRM/AMDGPU ioctl paths. The attacker manipulates or races the indirect buffer contents so that the parameter length observed during the initial lookup differs from the value consumed later. If the race is won, the kernel driver may use stale validation assumptions with attacker-influenced data, potentially causing an out-of-bounds access, GPU reset, kernel oops, or other memory-safety side effects. Successful exploitation is expected to be highly environment-dependent and local-only, with likely outcomes ranging from denial of service to possible privilege escalation if memory corruption can be made controllable.

How to fix it

Upgrade to a Linux kernel package from the operating system or distribution vendor that includes the AMDGPU VCN 4 fix for reusing the parameter length returned by vcn_v4_0_enc_find_ib_param instead of rereading it from the indirect buffer. If building kernels directly, ensure the fix corresponding to upstream commit dbb02b4755f8c1f3773263f2d779872c1c0c073a, or its stable-branch backport, is present. Reboot after installing the fixed kernel so the patched kernel and amdgpu module are active. Where immediate patching is not possible, reduce exposure by limiting local access to /dev/dri/card* and /dev/dri/renderD* devices, avoiding GPU device passthrough to untrusted containers or VMs, disabling unneeded video encode workloads, or temporarily disabling AMDGPU hardware access on systems where business impact is acceptable.

How to confirm the fix worked

Confirm the running kernel version with uname -r and compare it against the fixed kernel versions published by the relevant Linux distribution or appliance vendor. Validate that the active kernel package, not only an installed but inactive package, contains the AMDGPU VCN 4 backport for commit dbb02b4755f8c1f3773263f2d779872c1c0c073a. On source-based or custom kernels, inspect the AMDGPU VCN 4 encoder code to verify that the length returned by vcn_v4_0_enc_find_ib_param is reused rather than reread from the indirect buffer. After reboot, confirm the loaded amdgpu module comes from the patched kernel tree and monitor dmesg or journalctl for absence of recurring AMDGPU VCN encoder faults, ring timeouts, GPU resets, or kernel oops events under representative video encode workloads.

Typical attack path

1. Obtain local execution on a Linux system using an affected kernel and AMDGPU VCN 4-capable hardware.
2. Confirm access to AMDGPU DRM device nodes such as render or card devices under /dev/dri.
3. Create a crafted VCN 4 video encode indirect buffer containing attacker-controlled parameter fields and lengths.
4. Submit the buffer through AMDGPU DRM ioctl interfaces while racing changes to the indirect buffer contents between driver reads.
5. Trigger inconsistent parameter length handling in the kernel AMDGPU VCN encoder path.
6. Leverage the resulting fault for denial of service, GPU reset, kernel crash, or, if controllable, further kernel-level exploitation.

How to detect it

There is no known public exploit pattern and no network-level indicator for this local kernel driver issue. Detection should focus on evidence of suspicious local GPU device use followed by AMDGPU VCN encoder instability, GPU resets, kernel oops messages, or crashes. Review system logs from journald, dmesg, kern.log, syslog, auditd, and EDR telemetry for processes opening /dev/dri/card* or /dev/dri/renderD* shortly before amdgpu VCN errors. On Linux systems with audit rules for device access or ioctl monitoring, correlate DRM device access by unusual users, containers, or newly dropped binaries with kernel messages mentioning amdgpu, VCN, vcn_enc, ring timeouts, GPU faults, or kernel memory faults. Because normal graphics and media workloads can generate some AMDGPU messages, prioritize repeated crashes, unexpected activity on servers that do not normally perform video encoding, device access by untrusted workloads, and crashes that coincide with privilege-boundary changes or suspicious local execution.

• vcn_v4_0_enc_find_ib_param
• amdgpu: GPU fault detected
• amdgpu: ring vcn_enc timeout
• amdgpu: ring vcn_enc_0 timeout
• amdgpu: ring vcn_enc_1 timeout
• amdgpu: GPU reset begin
• amdgpu: GPU reset succeeded
• amdgpu: failed to send message
• amdgpu: VCN
• VCN encode
• vcn_enc
• /dev/dri/renderD
• /dev/dri/card
• BUG: unable to handle page fault
• BUG: kernel NULL pointer dereference
• general protection fault
• kernel BUG at drivers/gpu/drm/amd/amdgpu
• drivers/gpu/drm/amd/amdgpu

What your security team should do

• Prioritize patching shared Linux GPU systems, developer workstations, VDI hosts, container platforms, and GPU compute servers where untrusted or semi-trusted users can access AMDGPU devices.
• Inventory Linux hosts with AMD GPUs and exposed /dev/dri device nodes, including container and VM passthrough configurations.
• Apply vendor kernel updates and reboot promptly; verify that the patched kernel is the running kernel.
• Restrict membership in groups or policies that grant direct DRM/GPU device access, especially on multi-user systems.
• Avoid passing /dev/dri devices into untrusted containers until patched, or use device allow-lists and workload isolation controls.
• Monitor kernel logs for AMDGPU VCN encoder faults, GPU resets, ring timeouts, and kernel oops messages that may indicate attempted triggering.
• Treat suspicious GPU-driver crashes on multi-user systems as potential local exploitation attempts and preserve kernel logs for investigation.