CVE-2026-46220: Linux AMDGPU Kernel Panic DoS Vulnerability

Technical summary

CVE-2026-46220 affects the AMDGPU SDMA v4.0 ring emission code in the Linux kernel. The sdma_v4_0_ring_emit_fence() function contains two BUG_ON(addr & 0x3) assertions that verify fence writeback addresses are dword-aligned. These assertions are reachable from unprivileged userspace via the DRM_IOCTL_AMDGPU_CS ioctl path, which accepts compute shader job submissions. A crafted submission with a misaligned fence address triggers the assertion, causing a kernel panic in the scheduler worker thread. The fix converts both BUG_ON() calls to WARN_ON() calls, allowing the condition to be logged without terminating the kernel. Proper validation should occur at the CS ioctl entry point rather than during ring emission.

Business impact

This vulnerability enables a local denial-of-service attack against systems running affected Linux kernels with AMDGPU support. Any unprivileged local user can crash the entire operating system, disrupting services and potentially causing data loss from ungraceful shutdown. On multi-tenant systems, container hosts, or shared compute platforms, this poses a significant availability risk. The attack requires no special privileges, authentication, or system access beyond basic user-level ioctl permissions.

Affected systems

Linux kernel systems with AMD GPU (AMDGPU) driver support. The specific code path affected is sdma_v4_0_ring_emit_fence() in the SDMA v4.0 ring code. Any kernel version including this function without the fix is vulnerable. Systems using AMDGPU for graphics or compute (including RDNA, NAVI, and earlier GPU families supported by SDMA v4) are affected. Non-AMDGPU systems are not vulnerable.

Exploitability

Exploitability is straightforward for local attackers. The attack vector is a standard DRM ioctl that any unprivileged user can invoke. No special kernel capabilities, driver compilation flags, or hardware configuration is required—only local user access and the ability to execute code or use command-line tools. Proof-of-concept exploitation requires crafting a DRM_IOCTL_AMDGPU_CS command with a misaligned fence address, which is well within reach of a motivated attacker. Remote exploitation is not possible.

Remediation

Apply the kernel patch that replaces the two BUG_ON(addr & 0x3) assertions in sdma_v4_0_ring_emit_fence() with WARN_ON(addr & 0x3) equivalents. Additionally, ensure that proper validation of fence addresses occurs at the CS ioctl entry point before reaching the ring emission callback. Verify that your Linux distribution or kernel vendor has included commit b90250bd933afd1ba94d86d6b13821997b22b18e or an equivalent fix in their kernel builds. This is a low-complexity fix that should be backported to all stable kernel series.

Patch guidance

Verify the kernel version installed on affected systems and cross-reference against your Linux distribution or vendor's security advisory for the patched kernel version. The upstream fix was cherry-picked from commit b90250bd933afd1ba94d86d6b13821997b22b18e. Most distributions (Red Hat, Debian, Ubuntu, etc.) will backport this fix to their stable branches. Check your distribution's errata or security notices for the specific patched kernel build. Kernel rebuild or in-place kernel update may be required; plan reboot maintenance accordingly.

Detection guidance

Monitor system logs (dmesg, journalctl) for WARN_ON messages from sdma_v4_0_ring_emit_fence() that include misaligned address conditions. An increase in such warnings may indicate active exploitation attempts. On patched systems, the kernel will continue running and emit a warning instead of panicking, making this detectable. Intrusion detection systems can monitor for suspicious DRM_IOCTL_AMDGPU_CS submissions, though distinguishing malicious from benign usage may be challenging. Most effective detection is via kernel crash dumps: if an unpatched system crash correlates with graphics-related stack traces, this vulnerability may be the cause.

Why prioritize this

Although the CVSS score is moderate (5.5), the ease of exploitation and immediate impact warrant prioritization. Any unprivileged user can crash the entire system without race conditions or complex techniques, making this a high-availability risk. Organizations relying on AMDGPU compute or graphics must patch urgently. Systems in high-availability environments, shared hosting, or unattended compute clusters should be prioritized first.

Risk score, explained

CVSS 3.1 score of 5.5 (Medium severity) reflects a local-only attack vector (AV:L), low complexity (AC:L), low privilege requirement (PR:L), and high availability impact (A:H) with no confidentiality or integrity consequences. The score appropriately captures the severity of a local DoS, though the ease of exploitation and lack of any mitigating factors elevate practical risk beyond the numerical score for many environments. Organizations should weigh their exposure to local attackers and system criticality accordingly.

Frequently asked questions