CVE-2026-68251

What it actually does

The driver used BUG_ON() assertions in sdma6.0 error paths that unconditionally panic the kernel instead of logging a warning and continuing.

Why it matters to the business

Systems using affected AMD GPUs can suffer unexpected kernel crashes and reboots when the driver encounters specific internal conditions, causing downtime and loss of GPU workloads.

How an attack unfolds

An attacker with local access or the ability to trigger graphics operations triggers the error conditions in the sdma6.0 code path; the BUG_ON() then forces an immediate kernel panic, resulting in denial of service.

How to fix it

Update to a Linux kernel containing the referenced commit that replaces BUG_ON() with WARN_ON() in drm/amdgpu/sdma6.0.

How to confirm the fix worked

Confirm the kernel source contains WARN_ON() instead of BUG_ON() at the sdma6.0 locations described in the commit; test that the previously fatal conditions now only emit warnings.

Typical attack path

1. Obtain local code execution or submit crafted graphics commands
2. Trigger the sdma6.0 error conditions covered by the former BUG_ON() checks
3. Kernel panics and system reboots

How to detect it

Review kernel logs for amdgpu sdma6.0 BUG_ON() triggered panics or oops entries; correlate with graphics workload submissions preceding the crash.

What your security team should do

• Apply the kernel update containing the fix as soon as it is available for the distribution
• Monitor for kernel oops or panic logs referencing amdgpu sdma6.0
• Restrict unprivileged local access on systems where GPU stability is critical until patched