CVE-2026-46220

What it actually does

This is a local denial-of-service vulnerability in the Linux kernel AMDGPU DRM driver. The vulnerable SDMA4 fence-emission path uses BUG_ON() assertions to check whether fence writeback addresses are dword-aligned. A low-privileged local user can submit crafted AMDGPU command streams through DRM_IOCTL_AMDGPU_CS that reach these assertions with a misaligned fence address. Because BUG_ON() triggers a fatal kernel condition, exploitation can panic the kernel from a scheduler worker thread, crashing the host. The fix changes the fatal BUG_ON() behavior to WARN_ON(), so the invalid condition is logged without bringing down the kernel.

Why it matters to the business

Successful exploitation can cause affected Linux systems using vulnerable AMDGPU driver code to crash, resulting in service interruption, lost workloads, downtime for users, and potential disruption to GPU-accelerated compute, graphics, desktop, or virtualization workloads. The attacker needs local access and low privileges, so this is most relevant for multi-user Linux systems, shared workstations, GPU compute nodes, CI/build workers, desktop fleets, and environments where untrusted users or sandbox escapes can access DRM devices. It is not listed in CISA KEV, has no known ransomware association, and has very low EPSS, so broad internet-scale exploitation is unlikely; however, the operational impact of a local kernel panic can still be high on shared or production systems.

How an attack unfolds

An attacker first obtains local code execution as an unprivileged user on a Linux system with the vulnerable AMDGPU DRM driver available. The attacker then opens the AMDGPU DRM device and submits a specially crafted command stream through DRM_IOCTL_AMDGPU_CS. The submission causes the SDMA4 fence emission routine to process a fence writeback address that is not dword-aligned. In vulnerable kernels, the driver reaches BUG_ON(addr & 0x3), treating the condition as fatal rather than rejecting the invalid submission earlier in the command submission path. The BUG_ON fires inside a kernel scheduler worker context, causing a kernel panic and making the system unavailable until it reboots or is manually recovered.

How to fix it

Update the Linux kernel to a vendor release that includes the upstream AMDGPU fix replacing the fatal BUG_ON() assertions in sdma_v4_0_ring_emit_fence() with WARN_ON(). The upstream fix is associated with commit b90250bd933afd1ba94d86d6b13821997b22b18e, but production systems should normally consume the fix through distribution or appliance kernel packages rather than manually cherry-picking unless maintaining a custom kernel. No exact package fixed versions were provided, so track advisories from the relevant Linux distribution or kernel supplier. Where immediate patching is not possible, reduce exposure by limiting local shell access, restricting membership in groups that can access DRM/GPU devices such as video or render, applying device cgroup controls for containers, disabling access to AMDGPU DRM nodes for untrusted workloads, or temporarily moving untrusted workloads away from affected GPU-enabled hosts.

How to confirm the fix worked

Confirm remediation by verifying that the running kernel package includes the vendor fix for the AMDGPU SDMA4 fence-emission BUG_ON issue or contains upstream commit b90250bd933afd1ba94d86d6b13821997b22b18e. On source-based or custom kernels, inspect the AMDGPU SDMA4 implementation and confirm sdma_v4_0_ring_emit_fence() no longer uses BUG_ON(addr & 0x3) for the fence address alignment checks and instead logs a warning or rejects invalid submissions earlier. Operationally, confirm that systems have rebooted into the updated kernel, not merely installed it. Exposure can be assessed by checking whether AMDGPU is loaded and DRM device nodes are present; systems without AMDGPU hardware/driver use are generally not practically exposed to this driver path.

Typical attack path

1. Gain local access to an affected Linux system as a low-privileged user.
2. Confirm that an AMDGPU DRM device is present and accessible, typically through /dev/dri/renderD* or /dev/dri/card*.
3. Craft an AMDGPU command submission that results in a misaligned fence writeback address.
4. Submit the crafted command stream using DRM_IOCTL_AMDGPU_CS.
5. Trigger the vulnerable SDMA4 fence emission path containing BUG_ON(addr & 0x3).
6. Cause a kernel panic, crashing the host and interrupting workloads.

How to detect it

To determine whether exploitation may already have occurred, review kernel logs and persistent journal data for unexplained kernel panics, BUG reports, oops traces, or reboots involving the amdgpu driver, SDMA, fence emission, or DRM command submission. Relevant sources include journalctl -k output, /var/log/kern.log, /var/log/messages, /var/log/syslog, crash dump directories such as /var/crash, kdump/vmcore records, and system reboot history from last, last -x, or uptime monitoring. Look for panics in scheduler worker threads and stack traces containing sdma_v4_0_ring_emit_fence, amdgpu, drm_sched, or DRM_IOCTL_AMDGPU_CS-adjacent functions. Because this denial-of-service does not inherently create files, users, persistence, or network traffic, attribution to exploitation may require correlating crash timing with local user sessions, process accounting, audit logs for access to /dev/dri devices, container device pass-through events, and any suspicious GPU/DRM test binaries executed shortly before the crash.

• BUG_ON(addr & 0x3)
• sdma_v4_0_ring_emit_fence
• amdgpu
• DRM_IOCTL_AMDGPU_CS
• drm_sched
• kernel BUG
• Kernel panic
• Oops
• /dev/dri/renderD
• /dev/dri/card
• /var/crash
• vmcore
• kdump

What your security team should do

• Prioritize patching shared Linux GPU systems, multi-user workstations, GPU compute nodes, CI runners, and any host where untrusted users or containers can access AMDGPU DRM devices.
• Inventory systems with the amdgpu kernel module loaded and accessible /dev/dri devices, then map them to kernel versions and distribution advisory status.
• Ensure patched kernels are actually running by scheduling reboots or live-patch validation where applicable.
• Restrict access to /dev/dri/card* and /dev/dri/renderD* for untrusted users and containers until patching is complete.
• Review group memberships and container device pass-through policies that grant access to AMDGPU DRM devices.
• Monitor kernel logs for BUG, kernel panic, or WARN messages involving amdgpu SDMA fence emission, especially on systems that experienced unexplained reboots.
• Because this is not KEV-listed, has no known ransomware use, and has low EPSS, handle it as a local availability hardening issue unless the affected hosts support critical shared workloads.