CVE-2026-68110

What it actually does

This is a Linux kernel denial-of-service flaw in the AMDGPU DRM driver, specifically the SDMA 4.4.2 code path. Certain driver conditions incorrectly use BUG_ON(), which intentionally triggers a kernel BUG and can panic or crash the system. The upstream fix replaces BUG_ON() with WARN_ON(), so the kernel records a warning instead of terminating execution. The expected impact is local system instability or full host crash; the available information does not indicate remote code execution, privilege escalation, or data theft.

Why it matters to the business

Systems using affected Linux kernels with AMDGPU hardware or enabled AMDGPU driver support may be vulnerable to crashes that interrupt workloads, user sessions, graphics/GPU-accelerated services, or compute jobs. The issue was published recently, but it is not currently listed in CISA KEV, is not known to be used in ransomware campaigns, and has no public exploit maturity indicated, so prioritization should be based on exposure of AMDGPU-enabled Linux systems and tolerance for unplanned downtime.

How an attack unfolds

An attacker with the ability to exercise the affected AMDGPU driver path, typically through local access, a local account, or an application/container workload that can submit GPU operations, attempts to trigger the SDMA 4.4.2 condition guarded by BUG_ON(). On vulnerable kernels, reaching that condition causes the kernel to execute a BUG path rather than recover gracefully. This can produce a kernel oops or panic and may reboot or hang the system depending on kernel panic settings. After patching, the same condition should produce a warning instead of crashing the kernel.

How to fix it

Apply the vendor-provided Linux kernel update that includes the AMDGPU SDMA 4.4.2 fix replacing BUG_ON() with WARN_ON(). If no vendor package version is available yet, track the upstream fix associated with commit fa4f86a148271e325e95287630a3a15a9cd35fdc and deploy the first stable distribution kernel that backports it. Reboot into the updated kernel after installation. Where immediate patching is not possible, reduce exposure by limiting local shell access, restricting untrusted workloads from GPU/DRM devices, disabling GPU passthrough to untrusted guests or containers, and disabling or unloading the AMDGPU driver only if operationally acceptable.

How to confirm the fix worked

Confirm the running kernel, not only the installed package, has been updated by checking the active kernel version after reboot and comparing it with the distribution advisory or patched kernel changelog. Validate that the kernel source or vendor patch no longer uses BUG_ON() for the affected drm/amdgpu/sdma4.4.2 logic and instead uses WARN_ON(). Review dmesg or journal logs after validation workloads for warnings rather than kernel BUG or panic events. On systems without AMDGPU hardware or without the amdgpu module loaded, exposure is substantially reduced, but patching should still follow normal kernel maintenance practices.

Typical attack path

1. Identify a Linux system running an affected kernel with AMDGPU driver support and AMD GPU hardware exposed.
2. Obtain local ability to run code or submit GPU/DRM operations on the system.
3. Trigger the vulnerable AMDGPU SDMA 4.4.2 driver condition through crafted or abnormal GPU activity.
4. Cause the kernel to hit BUG_ON(), resulting in a kernel BUG, oops, panic, reboot, hang, or service interruption.
5. Repeat the trigger to create recurring denial of service until the kernel is patched or GPU access is restricted.

How to detect it

Look for evidence of prior denial-of-service activity in kernel and system logs rather than persistence artifacts. Relevant sources include dmesg, journalctl kernel logs, /var/log/kern.log, /var/log/messages, /var/log/syslog, crash dumps, kdump/vmcore records, hypervisor reset telemetry, EDR reboot events, and GPU workload scheduler logs. Search for kernel BUG, oops, panic, or unexpected reboot events that also reference amdgpu, SDMA, sdma4, or DRM around the same timestamp. Because this flaw is a crash condition and no public exploitation is indicated, absence of logs may be inconclusive if volatile kernel logs were lost during reboot. Repeated crashes on AMDGPU-enabled systems following GPU activity or local user/container jobs are more suspicious than isolated hardware or power failures.

• kernel BUG
• BUG: kernel NULL pointer dereference
• Kernel panic
• Oops:
• amdgpu
• AMDGPU
• sdma4
• sdma4.4.2
• SDMA
• drm/amdgpu
• drm:amdgpu
• GPU reset
• /dev/dri/card
• /dev/dri/renderD
• fa4f86a148271e325e95287630a3a15a9cd35fdc

What your security team should do

• Inventory Linux systems with AMD GPUs, loaded amdgpu modules, GPU passthrough, or workloads that can access /dev/dri devices.
• Prioritize kernel updates for AMDGPU-enabled servers, workstations, VDI systems, GPU compute nodes, and multi-user systems where local users or untrusted workloads can exercise GPU drivers.
• Monitor vendor kernel advisories for patched package versions because fixed versions were not provided in the input data.
• Until patched, restrict access to GPU device nodes and avoid granting untrusted containers or guests direct access to AMDGPU devices.
• Review recent kernel panic, oops, reboot, and GPU reset telemetry for signs of repeated AMDGPU SDMA-related crashes.
• After patching, reboot systems and verify they are running the updated kernel, since kernel package installation alone is not sufficient.