CVE-2026-68113

What it actually does

This flaw is a denial-of-service condition in the Linux kernel AMDGPU DRM driver for GFX12-class AMD GPUs. Certain error or unexpected-state paths used BUG_ON(), which intentionally triggers a kernel crash when reached. Replacing BUG_ON() with WARN_ON() changes the behavior from a full system panic to a warning, meaning the vulnerable versions can allow a reachable GPU-driver condition to crash the entire host. The impact is availability loss rather than privilege escalation or data compromise based on the available description.

Why it matters to the business

Systems using affected Linux kernel builds with AMDGPU GFX12 hardware may experience sudden crashes and service interruption if the vulnerable driver path is triggered. This is most relevant for workstations, GPU-accelerated servers, VDI hosts, graphics workloads, rendering farms, and compute environments using AMD GPUs. The CVE is recently published, is not in CISA KEV, has no known ransomware association, and currently has no public exploit maturity, so urgency is moderate unless the organization relies heavily on AMD GPU availability or exposes GPU access to untrusted local users or workloads.

How an attack unfolds

An attacker would need a way to reach the vulnerable AMDGPU driver code path, most plausibly from a local account, container, desktop session, GPU-accelerated workload, or application with access to DRM/GPU device interfaces. The attacker would interact with the GPU driver in a way that causes the specific GFX12 assertion condition to evaluate true. In vulnerable kernels, the BUG_ON() macro treats that condition as fatal and crashes the kernel, immediately disrupting the host and any workloads running on it. On fixed kernels, the same condition should generate a warning rather than a system-wide crash.

How to fix it

Update to a Linux kernel version from the relevant distribution or upstream stable branch that includes the AMDGPU GFX12 change replacing the crash-inducing BUG_ON() with WARN_ON(), specifically the fix associated with upstream commit f952076f76d62f783e8ba4995a7c400d39354ccf or its backports. Because no exact fixed package versions were provided, use vendor advisories for the deployed distribution to identify the corrected kernel package. After updating, reboot into the fixed kernel. As temporary mitigations, restrict local access to GPU device nodes, avoid granting untrusted containers or workloads direct GPU access, limit membership in groups that can access /dev/dri devices, and consider disabling or avoiding affected AMDGPU GFX12 acceleration on high-risk multi-user systems until patched.

How to confirm the fix worked

Confirm the running kernel is the updated vendor kernel, not merely that the package is installed. Validate with commands such as uname -r and the distribution package manager, then compare against the vendor advisory for this CVE or the kernel changelog containing the AMDGPU GFX12 BUG_ON-to-WARN_ON fix. Review boot logs after reboot to verify the amdgpu module loads normally. If source or debug package validation is available, confirm the relevant AMDGPU GFX12 code no longer uses BUG_ON() for the affected condition and instead uses WARN_ON(). Also verify that untrusted users or containers do not have unnecessary access to /dev/dri/renderD* or /dev/dri/card* devices.

Typical attack path

1. Identify a Linux system using the AMDGPU kernel driver with GFX12-class AMD GPU hardware.
2. Obtain local execution or access to software capable of interacting with the GPU/DRM interface, such as a desktop session, compute job, container with GPU passthrough, or local user account.
3. Trigger the AMDGPU GFX12 driver state that reaches the vulnerable BUG_ON() assertion.
4. Cause the kernel to panic or crash, resulting in denial of service for the host and hosted workloads.
5. Repeat the trigger after reboot if access remains available and the kernel is not patched.

How to detect it

To determine whether this was already exploited or triggered, review kernel logs, persistent journal data, crash dumps, and system availability telemetry for unexpected reboots or kernel panics involving the AMDGPU driver. Useful sources include journalctl -k, /var/log/kern.log, /var/log/messages, /var/log/syslog, pstore/ramoops logs, kdump vmcore records, hypervisor reset events, and monitoring alerts for sudden host reboots. Focus searches on AMDGPU, DRM, GFX12, kernel BUG, panic, oops, and call traces occurring shortly before an unexpected reboot. If the host supports multiple local users or GPU-enabled containers, correlate crash times with logins, batch jobs, container starts, GPU workloads, render jobs, or access to /dev/dri devices. There are no public threat actors, known exploit campaigns, or ransomware usage associated with this issue based on the supplied data, so detection should center on crash artifacts and local activity correlation rather than known malware indicators.

• BUG_ON
• kernel BUG
• kernel BUG at drivers/gpu/drm/amd/amdgpu
• Kernel panic - not syncing
• Oops:
• Call Trace:
• amdgpu
• drm/amdgpu
• gfx12
• /dev/dri/card
• /dev/dri/renderD
• /sys/class/drm
• pstore
• ramoops
• vmcore

What your security team should do

• Inventory Linux systems using AMDGPU hardware, especially GFX12-class AMD GPUs and hosts exposing /dev/dri devices to users, containers, VDI sessions, or compute jobs.
• Prioritize patching GPU-enabled multi-user systems, GPU compute clusters, VDI hosts, and production servers where a reboot or crash would have operational impact.
• Track distribution security advisories for the exact fixed kernel package and schedule a reboot into the corrected kernel after installation.
• Temporarily restrict GPU device access for untrusted users and workloads until systems are confirmed fixed.
• Monitor kernel logs and crash telemetry for AMDGPU-related BUG, panic, oops, or watchdog events that may indicate attempted or accidental triggering.
• Because this is not currently KEV-listed and has no known public exploit maturity, handle through normal expedited kernel patching rather than emergency incident response unless crashes or suspicious local activity are observed.