CVE-2026-68112

What it actually does

This is a Linux kernel denial-of-service issue in the AMDGPU DRM driver for gfx9.4.3 hardware paths. The vulnerable code uses BUG_ON(), which deliberately crashes the kernel when certain unexpected driver states occur. The fix changes those conditions to WARN_ON(), meaning the kernel logs a warning instead of panicking. Practical impact is system-wide kernel panic or forced reboot if an attacker or workload can trigger the affected AMDGPU driver condition.

Why it matters to the business

Systems using affected Linux kernels with relevant AMD GPU hardware may experience sudden crashes, service interruption, failed GPU workloads, and potential data loss from abrupt reboots. This is most operationally significant for GPU-backed compute, VDI, rendering, AI/ML, HPC, or multi-user Linux environments where local users or submitted workloads can interact with GPU devices. The issue is newly published, is not listed in CISA KEV, has no known public exploit maturity reported, and there is no indication from the provided data that it is used in ransomware campaigns, so urgency should be driven primarily by exposure of GPU-accessible Linux systems and availability requirements.

How an attack unfolds

An attacker first needs a path to interact with a vulnerable Linux system using the affected AMDGPU driver, typically through local shell access, a container or workload with GPU device access, a desktop session, or an application path that can submit GPU work. The attacker then causes the driver to enter one of the unexpected gfx9.4.3 states guarded by BUG_ON(). In vulnerable kernels, the BUG_ON() assertion does not fail safely; it intentionally triggers a kernel crash. Because the failure occurs in kernel space, the result is not limited to the attacking process: the entire host can panic, reboot, or become unavailable. The patched behavior logs a warning instead, preventing the assertion from becoming a system-wide denial of service.

How to fix it

Apply a Linux kernel update from the operating system or kernel vendor that includes the upstream AMDGPU change replacing the relevant BUG_ON() checks with WARN_ON() for gfx9.4.3. No exact fixed package versions were provided in the input, so use vendor advisories, distribution security trackers, or kernel changelogs to identify the first fixed kernel for each platform. Where immediate patching is not possible, reduce exposure by limiting local shell access, restricting access to GPU device nodes such as /dev/dri/card* and /dev/dri/renderD*, disabling GPU passthrough to untrusted guests or containers, moving untrusted workloads away from affected GPU hosts, or temporarily disabling the amdgpu driver on systems where GPU functionality is not required.

How to confirm the fix worked

Confirm remediation by verifying the running kernel package/version is at or above the vendor-fixed release and that the running kernel contains the AMDGPU gfx9.4.3 change replacing the crash-inducing BUG_ON() behavior with WARN_ON(). Reboot into the updated kernel after installation; merely installing a kernel package is not sufficient if the old kernel remains active. Validate exposure by checking whether the amdgpu module is loaded, whether AMD GPU DRM devices are present, and whether untrusted users, containers, virtual machines, or batch jobs can access GPU device nodes. Review kernel logs after patching to ensure comparable conditions generate warnings rather than kernel panics.

Typical attack path

1. Identify a Linux host running an affected kernel with the AMDGPU DRM driver and compatible AMD GPU hardware exposed.
2. Obtain local access or the ability to run GPU-enabled workloads, sessions, or containers on the host.
3. Interact with the GPU through normal device interfaces such as DRM/render nodes or GPU compute/graphics workloads.
4. Trigger the vulnerable gfx9.4.3 driver condition that reaches a BUG_ON() assertion.
5. Cause a kernel panic or crash, interrupting all workloads on the system.
6. Repeat the trigger to create recurring outages if the host is rebooted without patching or mitigation.

How to detect it

Because this is a denial-of-service condition in kernel driver logic, successful exploitation may leave limited forensic evidence beyond kernel crash artifacts, system reboot records, and logs immediately before panic. Review kernel logs, persistent journal data, crash dumps, netconsole/serial console output, hypervisor reset events, and hardware management controller logs for amdgpu, DRM, gfx9.4.3, BUG, kernel panic, or oops messages. Correlate crash times with local logins, batch jobs, container starts, GPU workload submissions, render node access, and changes in GPU-intensive processes. On systems with kdump or crashkernel enabled, preserve vmcore files and inspect the panic backtrace for amdgpu or drm frames. Repeated crashes tied to GPU workload execution or access to /dev/dri devices should be treated as suspicious until patched behavior is confirmed.

• BUG: kernel BUG
• kernel BUG at
• Kernel panic - not syncing
• Oops:
• amdgpu
• drm/amdgpu
• gfx9.4.3
• /dev/dri/card
• /dev/dri/renderD
• amdgpu:
• [drm]
• vmcore
• /var/crash
• /var/lib/systemd/coredump
• kdump

What your security team should do

• Inventory Linux systems with AMD GPUs, the amdgpu kernel module loaded, and exposed /dev/dri device nodes.
• Prioritize patching GPU-backed multi-user, compute, VDI, container, and virtualization hosts where untrusted or semi-trusted workloads can access the GPU.
• Track operating system and kernel vendor advisories for exact fixed versions because none were provided with the vulnerability metadata.
• Reboot systems into the patched kernel and verify the active kernel version, not only the installed package version.
• Restrict GPU device access to trusted users and workloads until patching is complete.
• Monitor kernel logs and crash telemetry for amdgpu-related BUG, panic, oops, or reboot events that could indicate attempted triggering.
• For high-availability GPU services, schedule controlled maintenance because remediation is likely to require a kernel update and reboot.