CVE-2026-46276: Linux amdgpu Kernel Panic on RDNA4 RX 9070 XT GPUs

Technical summary

CVE-2026-46276 is a kernel panic in the amdgpu driver affecting RDNA4 (GFX 12) GPUs. RDNA4 removes on-chip GDS (Global Data Share), GWS (Global Wave Sync), and OA (Ordered Append) memory resources, correctly initializing their sizes to zero. However, amdgpu_ttm_init() unconditionally calls amdgpu_ttm_init_on_chip() for all three resources regardless of their size. When size is zero, this cascades to ttm_range_man_init() → drm_mm_init(mm, 0, 0), which immediately triggers DRM_MM_BUG_ON(start + size <= start)—a condition that is always true when size equals zero. The kernel crashes with a BUG assertion during amdgpu modprobe. The fix adds an early return in amdgpu_ttm_init_on_chip() when size_in_page is zero, skipping TTM resource manager registration for absent hardware resources. The bug only manifests with CONFIG_DRM_DEBUG_MM enabled in the kernel config, explaining why it remained undetected despite RDNA4 being in market for over a year.

Business impact

This vulnerability prevents Linux systems with AMD Radeon RX 9070 XT GPUs from booting when amdgpu driver is loaded. For organizations deploying these newer AMD GPUs on Linux servers or workstations—particularly in AI/ML, HPC, or rendering workloads—the system becomes unbootable until a patched kernel is available. Development teams and early adopters of RDNA4 hardware face immediate operational disruption. The impact is limited to systems with CONFIG_DRM_DEBUG_MM enabled, but this is unpredictable at deployment time, creating a boot-time lottery for affected hardware combinations.

Affected systems

The vulnerability affects Linux kernel versions prior to the patch on systems using AMD RDNA4 (GFX 12) graphics hardware, specifically the RX 9070 XT. Only kernels compiled with CONFIG_DRM_DEBUG_MM enabled will trigger the crash; however, determining this config option at deployment time is non-trivial. The issue does not affect other GPU architectures (RDNA3, RDNA2, RDNA1, or older) since they retain on-chip memory resources. Any Linux distribution kernel that includes amdgpu driver support and is compiled with debug memory management enabled is potentially vulnerable.

Exploitability

This is not an exploitable vulnerability in the traditional sense—it is a logic error that causes a kernel panic rather than enabling privilege escalation or information disclosure. However, it is trivially triggered during normal system boot when amdgpu loads on RDNA4 hardware. The vulnerability requires local system access (modprobe execution during boot) and affects availability rather than confidentiality or integrity. An attacker cannot weaponize this for remote code execution, but it effectively denies service to any system that loads the vulnerable driver on affected hardware.

Remediation

Update the Linux kernel to a version containing the fix commit 5719ce5865279cad4fd5f01011fe037168503f2d or later. Most Linux distributions will issue kernel updates addressing this issue once patches are released. For systems currently unable to boot with RDNA4 GPUs, either (1) update the kernel to a patched version, (2) boot with an older kernel that predates amdgpu RDNA4 support, or (3) disable amdgpu driver loading in the bootloader and use fallback graphics support until the kernel is updated. Verify patched kernel availability from your Linux distribution's security advisory pages.

Patch guidance

Monitor your Linux distribution (Ubuntu, Red Hat, Debian, SUSE, etc.) for kernel security updates addressing CVE-2026-46276. The fix is a minimal, non-invasive change to amdgpu_ttm_init_on_chip() that adds a size check before resource initialization. When a patched kernel becomes available, standard kernel update procedures apply: install the updated package and reboot. The patch has been cherry-picked from upstream commit 5719ce5865279cad4fd5f01011fe037168503f2d; verify your distribution's advisory to confirm the exact version or release date when the fix is included.

Detection guidance

Systems running vulnerable kernels will experience an immediate kernel panic during boot with a DRM_MM_BUG_ON() assertion message if amdgpu is loaded on RDNA4 hardware. Check kernel logs or the oops report at the referenced oops.fenrus.org URL for the specific panic signature. To check if a currently running kernel is vulnerable, verify: (1) is amdgpu driver loaded (lsmod | grep amdgpu), (2) is the system running RDNA4 hardware (lspci | grep -i radeon), and (3) was the kernel compiled with CONFIG_DRM_DEBUG_MM=y (check /boot/config-* or from dmesg). Systems that boot successfully despite having RDNA4 hardware likely have CONFIG_DRM_DEBUG_MM disabled and are not experiencing the crash, but may still benefit from the fix for future robustness.

Why prioritize this

Although this vulnerability scores MEDIUM (5.5 CVSS), it should be prioritized for kernel updates because: (1) it causes complete denial of service (system unbootable) for affected hardware, (2) RDNA4 is new hardware that organizations are actively deploying, and (3) the fix is minimal and carries negligible risk of regression. Unlike vulnerabilities that require exploitation steps, this triggers automatically during normal boot. Organizations deploying RX 9070 XT GPUs on Linux must apply the patch immediately to restore system functionality.

Risk score, explained

CVSS 3.1 score of 5.5 (MEDIUM) reflects: Attack Vector Local (system boot required), Attack Complexity Low (no special conditions), Privileges Required Low (modprobe execution at boot), User Interaction None, Scope Unchanged, and Availability Impact High (kernel panic). Confidentiality and Integrity impacts are None. The score appropriately captures that this is a high-severity availability issue without exploitability for privilege escalation. The MEDIUM classification slightly underweights the fact that this makes RDNA4 hardware completely unusable on affected Linux systems, but the CVSS framework does not distinguish between 'partial unavailability' and 'total unavailability' below the CRITICAL threshold.

Frequently asked questions