CVE-2026-68106

What it actually does

This vulnerability is a denial-of-service flaw in the Linux kernel AMDGPU DRM driver. When the AMD UVD video decode path processes malformed H.264 input with a frame width or height smaller than 16 pixels, internal macroblock calculations can produce zero values. Those zero values are later used in a division operation while calculating decoded-picture-buffer sizing, causing a kernel division-by-zero fault. Depending on kernel configuration and runtime conditions, exploitation may crash the video decode path, trigger a kernel oops, hang the GPU driver, or panic the system.

Why it matters to the business

Systems using AMD GPUs with affected Linux kernels may be destabilized by malformed or intentionally crafted video input. The most likely impact is loss of availability for workstations, media-processing systems, VDI hosts, GPU-enabled desktops, or services that decode untrusted H.264 content. It 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 still be addressed through normal kernel update processes where AMDGPU video decoding is in use.

How an attack unfolds

An attacker needs a path to make an affected system process specially crafted H.264 video content through the AMDGPU UVD decode path. This could occur by convincing a user to open a malicious media file, embedding malformed video in content processed by a browser or media application that uses hardware decode, or submitting crafted media to a service that transcodes or inspects video using affected AMD GPU acceleration. The malformed stream specifies a width or height below 16 pixels. The vulnerable kernel driver converts those dimensions into macroblock counts, which become zero, and then performs a calculation that divides by the resulting zero value. The kernel fault can interrupt the graphics/video subsystem and may crash or hang the host, resulting in denial of service. There is no indication from the provided data that this flaw enables code execution or privilege escalation.

How to fix it

Upgrade to a Linux kernel build that includes the upstream AMDGPU fix for invalid UVD dimensions. The fix rejects frames with width less than 16 or height less than 16 before calculations that depend on macroblock dimensions. Because no affected product list or package-specific fixed versions were provided, use the fixed kernel packages supplied by the relevant Linux distribution, hardware appliance vendor, or kernel maintainer. As temporary mitigations, avoid processing untrusted video content on affected systems, disable hardware-accelerated video decoding where practical, route untrusted media processing to isolated sandboxes, and restrict access to GPU-accelerated media-processing services.

How to confirm the fix worked

Confirm that the running kernel includes the AMDGPU patch that validates UVD frame dimensions before H.264 decode buffer calculations. Validate through vendor advisories, distribution package changelogs, kernel source inspection, or by confirming that the relevant fixed kernel package is installed and booted. On Linux systems, compare the installed and running kernel versions using package-manager output and `uname -r`; ensure the active kernel is the updated one after reboot. Where safe and authorized, regression testing can include attempting to process malformed H.264 samples with dimensions below 16 pixels and confirming the system rejects the input without a kernel oops, GPU reset loop, or crash.

Typical attack path

1. Identify a Linux system using an affected kernel with AMDGPU DRM/UVD hardware video decoding enabled.
2. Prepare malformed H.264 content with width or height values smaller than 16 pixels.
3. Deliver the crafted media through a user-facing application, browser, media pipeline, or GPU-accelerated video-processing workflow.
4. Cause the target system to decode the content using the AMDGPU UVD H.264 decode path.
5. Trigger the division-by-zero condition in the kernel driver.
6. Induce a kernel oops, GPU driver failure, system hang, or crash, causing denial of service.

How to detect it

Review kernel logs, system journals, crash dumps, and GPU driver logs for evidence of a division-by-zero fault or kernel oops in AMDGPU UVD H.264 decode paths. Useful sources include `journalctl -k`, `/var/log/kern.log`, `/var/log/messages`, `/var/log/syslog`, `dmesg`, kernel crash dump directories such as `/var/crash`, and endpoint telemetry that captures kernel panics or GPU resets. Look for crashes that occur immediately after opening, previewing, transcoding, indexing, or scanning H.264 media. Correlate timestamps with browser activity, media-player execution, file uploads, transcoding jobs, content moderation pipelines, or email/web downloads. Since this is a denial-of-service issue and the provided data does not include known threat actors or public exploit artifacts, detection should focus on crash signatures and suspicious malformed video inputs rather than malware indicators.

• divide error
• division by zero
• kernel BUG
• Oops: 0000
• RIP:
• amdgpu
• drm/amdgpu
• uvd
• UVD
• H264
• H.264
• num_dpb_buffer
• width_in_mb
• height_in_mb
• GPU reset
• amdgpu: GPU reset
• /var/crash
• /var/log/kern.log
• /var/log/messages
• /var/log/syslog

What your security team should do

• Inventory Linux endpoints, workstations, VDI hosts, render nodes, and media-processing systems that use AMD GPUs with the AMDGPU driver enabled.
• Prioritize patching systems that process untrusted media, browse the internet, run desktop workloads, provide shared GPU services, or perform automated video ingestion/transcoding.
• Apply vendor-provided kernel updates and reboot systems so the fixed kernel is actually running.
• Until patched, disable hardware-accelerated H.264 decoding or isolate untrusted media processing in sandboxed, non-critical environments where feasible.
• Monitor kernel and system logs for division-by-zero, kernel oops, GPU reset, or AMDGPU/UVD errors following media playback or video-processing activity.
• Treat repeated crashes associated with H.264 content or AMDGPU UVD decode as potentially malicious until malformed media and exploitation are ruled out.
• Because the vulnerability is not KEV-listed and has no known exploit maturity in the provided data, handle it as normal-priority patching unless the organization has high exposure to untrusted media processing.