CVE-2026-68109

What it actually does

This is a Linux kernel denial-of-service flaw in the AMDGPU SDMA 7.1 driver path. The vulnerable code uses BUG_ON() for conditions that should not require a fatal kernel stop; if those conditions are reached, the kernel can panic instead of logging a warning and continuing or failing the operation safely. The practical impact is system crash or forced reboot on systems using affected AMDGPU hardware/driver paths, most likely requiring local ability to exercise the GPU device interface or submit GPU workloads.

Why it matters to the business

Affected Linux systems with AMD GPUs may experience unexpected crashes, interrupting desktop, workstation, compute, VDI, rendering, ML, or GPU-accelerated workloads. Because this is not known to be exploited, is not in CISA KEV, and has no reported public exploit maturity, the immediate risk is lower than remotely exploitable vulnerabilities, but organizations operating shared GPU systems should still prioritize kernel updates to avoid deliberate or accidental outages.

How an attack unfolds

An attacker first needs access to a system where the vulnerable AMDGPU SDMA 7.1 driver code is present and active. They then exercise GPU functionality through normal local interfaces such as DRM render nodes or GPU compute/graphics APIs in a way that reaches the vulnerable SDMA driver condition. On affected kernels, the driver invokes BUG_ON(), which intentionally halts execution and can trigger a kernel panic. The result is denial of service: active sessions and workloads are interrupted and the host may require reboot or recover through panic handling. There is no indication from the provided data of remote code execution, privilege escalation, known weaponization, ransomware use, or active exploitation.

How to fix it

Upgrade to a Linux kernel version that includes the upstream AMDGPU fix replacing the fatal BUG_ON() behavior with WARN_ON() for the SDMA 7.1 path. If vendor fixed package versions are not yet available, track the relevant distribution kernel advisories and apply the first kernel update that includes the fix derived from upstream commit c4f230b51cf2d3e7e8b1c800331f3dbed2a9e3f5. Reboot systems after kernel updates to ensure the fixed kernel is running. Where immediate patching is not possible, reduce exposure by limiting local shell access, restricting access to /dev/dri and GPU passthrough devices to trusted users and workloads, disabling untrusted GPU compute jobs, and isolating shared GPU workloads on systems that can tolerate outage.

How to confirm the fix worked

Confirm the running kernel, not only the installed package, has been updated by checking uname -r after reboot and comparing it to the distribution advisory for this fix. Validate whether the host uses the AMDGPU driver and relevant hardware by checking loaded modules and kernel logs for amdgpu initialization. Source-level validation can confirm that the affected SDMA 7.1 code path no longer contains the fatal BUG_ON() behavior and instead uses WARN_ON(). Operationally, monitor for absence of recurring kernel panics involving amdgpu or sdma after patching. For fleet exposure checks, inventory Linux systems with AMD GPUs, the amdgpu kernel module loaded, and GPU device nodes exposed to local users or containers.

Typical attack path

1. Identify a Linux host using the AMDGPU driver with hardware that reaches the SDMA 7.1 code path.
2. Obtain local access or workload execution capability on the host, such as an interactive account, container with GPU device access, or submitted GPU job.
3. Open or use exposed GPU device interfaces such as DRM render nodes or AMD GPU compute/graphics APIs.
4. Trigger the driver condition that reaches the vulnerable BUG_ON() assertion.
5. Cause a kernel panic or system crash, disrupting users and GPU workloads.

How to detect it

To determine whether this was already exploited or triggered, review kernel logs, persistent journal entries, crash dumps, and system reboot records for kernel panics involving the AMDGPU driver or SDMA shortly before unexpected reboots. Useful sources include journalctl -k, /var/log/kern.log, /var/log/messages, /var/log/syslog, pstore/ramoops records, kdump/vmcore artifacts, hypervisor console logs, and GPU workload scheduler logs. Look for kernel BUG or panic messages referencing amdgpu, SDMA, DRM, or the SDMA 7.1 source file. Correlate crash times with local logins, batch jobs, containers, GPU compute workloads, or changes in access to /dev/dri devices. Because no public exploit indicators or threat actors are provided, detection should focus on behavioral evidence of panic-triggering rather than malware-specific artifacts.

• kernel BUG
• Kernel panic
• Oops:
• BUG: unable to handle kernel
• amdgpu
• drm/amdgpu
• sdma7.1
• sdma_v7_1
• drivers/gpu/drm/amd/amdgpu
• /dev/dri/renderD
• /dev/dri/card
• pstore
• ramoops
• vmcore
• kdump

What your security team should do

• Inventory Linux systems using AMDGPU, especially shared GPU servers, workstations, VDI hosts, CI runners, render farms, and ML/compute nodes.
• Prioritize kernel updates for systems where untrusted or semi-trusted users can run GPU workloads or access /dev/dri devices.
• Restrict GPU device access to trusted users and workloads until patched, including container GPU passthrough and render-node permissions.
• Review recent kernel panic, reboot, and GPU-driver error logs for amdgpu or SDMA-related crashes.
• Coordinate maintenance windows for kernel patching and required reboots on GPU-dependent production systems.
• Track Linux distribution advisories for exact fixed kernel package versions because no product-specific fixed versions were provided in the input.