CVE-2026-68115

What it actually does

This issue affects the Linux kernel AMDGPU DRM driver for GFX10-class AMD GPUs. Certain driver code paths used BUG_ON(), which intentionally triggers a kernel panic when a condition is hit. Replacing those assertions with WARN_ON() prevents the entire kernel from crashing and instead logs a warning. The practical technical impact is local denial of service: a user or workload capable of exercising the affected AMDGPU graphics path may be able to crash the host kernel, causing a system reboot or outage.

Why it matters to the business

Systems using affected Linux kernels with AMD GFX10-era GPUs may be vulnerable to unexpected crashes if the vulnerable graphics driver path is triggered. This can interrupt desktops, GPU workstations, visualization nodes, CI/build systems, or compute workloads that depend on AMDGPU acceleration. There is no indication from the provided data that this is remotely exploitable, publicly weaponized, listed in CISA KEV, or used in ransomware campaigns, so urgency should be driven primarily by exposure of AMDGPU-enabled Linux systems and tolerance for downtime.

How an attack unfolds

An attacker first needs access to a Linux system using the affected AMDGPU driver path, typically through a local account, graphical session, container or workload with access to GPU devices, or another mechanism that can interact with the DRM/AMDGPU interface. The attacker then exercises the vulnerable GFX10 code path in a way that causes the BUG_ON() condition to evaluate as true. Because BUG_ON() is a fatal kernel assertion, the kernel panics rather than safely handling or logging the condition. The result is a host crash, loss of active sessions, interrupted workloads, and possible reboot depending on system configuration. The fixed kernel changes this behavior so the condition produces a warning instead of a full system crash.

How to fix it

Apply the Linux kernel update from the relevant distribution or vendor that includes the upstream AMDGPU fix replacing the fatal BUG_ON() with WARN_ON() in the drm/amdgpu/gfx10 code path. Because no fixed package versions were provided, use the latest security-supported kernel available for the affected distribution, appliance, or hardware vendor platform. Reboot systems after installing the updated kernel to ensure the patched AMDGPU driver is active. Where immediate patching is not possible, reduce exposure by limiting local user access to GPU device nodes such as /dev/dri/*, restricting untrusted graphical or GPU workloads, disabling GPU passthrough to untrusted guests or containers where feasible, and monitoring for AMDGPU-related kernel panics. Avoid relying on mitigation alone for systems where availability is important.

How to confirm the fix worked

Confirm remediation by verifying the running kernel is the vendor-patched version, not merely that an updated package is installed. On Linux systems, compare `uname -r` against the distribution advisory for this vulnerability and confirm the system has been rebooted after the kernel update. Review vendor changelogs or kernel source packages for the AMDGPU GFX10 change that replaces BUG_ON() with WARN_ON(). Validate exposure by checking whether the system loads the amdgpu module, has AMD GPU hardware present, and exposes DRM device nodes under /dev/dri. For regression validation, monitor kernel logs during normal GPU workloads and confirm AMDGPU warnings do not escalate into kernel panic or reboot events.

Typical attack path

1. Identify a Linux host using the AMDGPU kernel driver with an affected kernel version and AMD GFX10-class GPU hardware.
2. Obtain local ability to interact with GPU/DRM interfaces, such as through a user session, graphics workload, or access to relevant /dev/dri device nodes.
3. Trigger the vulnerable AMDGPU GFX10 code path that reaches the fatal BUG_ON() assertion.
4. Cause a kernel panic, resulting in denial of service, workload interruption, and possible system reboot.
5. Repeat the trigger to create recurring instability until the kernel is updated or GPU device access is restricted.

How to detect it

To assess possible prior exploitation or triggering, review kernel and system logs for unexpected panics, reboots, and AMDGPU/DRM errors preceding a crash. Useful sources include `journalctl -k`, `/var/log/kern.log`, `/var/log/messages`, `/var/log/syslog`, persistent systemd journal entries from the previous boot, crash dump directories such as `/var/crash`, kdump/vmcore storage, and hardware or fleet management reboot telemetry. Look for sequences where AMDGPU or DRM messages appear immediately before `kernel panic`, `BUG:`, `Oops`, watchdog resets, or unplanned boot events. Also review audit logs and session history for users or workloads accessing `/dev/dri/card*` or `/dev/dri/renderD*` shortly before the crash, especially on shared systems. No public exploit-specific payload, file artifact, network signature, or named threat actor is indicated by the provided data, so detection should focus on behavioral evidence of AMDGPU-triggered kernel crashes rather than a unique IOC.

• BUG: kernel BUG
• kernel BUG at
• Kernel panic - not syncing
• Oops:
• amdgpu
• drm/amdgpu
• gfx10
• /dev/dri/card0
• /dev/dri/renderD128
• /var/crash
• vmcore
• kdump

What your security team should do

• Inventory Linux systems using AMDGPU, especially those with AMD GFX10-class GPUs and systems that expose /dev/dri devices to users, containers, virtual machines, or shared compute workloads.
• Prioritize patching GPU workstations, multi-user Linux desktops, remote visualization systems, CI runners, and GPU compute hosts where a local denial of service could disrupt operations.
• Deploy the latest vendor-supported kernel containing the AMDGPU fix and reboot systems to activate it.
• Until patching is complete, restrict access to GPU device nodes for untrusted users and workloads, and review container or virtualization configurations that pass through AMD GPU devices.
• Enable or review monitoring for kernel panic, unexpected reboot, amdgpu driver errors, and DRM subsystem warnings.
• Because exploit maturity is currently reported as none and the issue is not listed in CISA KEV, treat this as an availability-hardening priority rather than an emergency internet-facing remote compromise scenario unless local untrusted GPU access is common.