CVE-2026-46276

What it actually does

This flaw is a Linux kernel denial-of-service condition in the AMDGPU DRM driver initialization path for RDNA4/GFX12 hardware. RDNA4 removes the GDS, GWS, and OA on-chip memory resources, leaving their sizes as zero. The vulnerable code still attempts to initialize TTM range managers for those zero-sized resources, which can call drm_mm_init() with a zero-length range. When the kernel is built with CONFIG_DRM_DEBUG_MM enabled, DRM_MM_BUG_ON() asserts and triggers a kernel crash during amdgpu module initialization. The practical technical impact is a local kernel crash or boot/module-load failure on affected AMD RDNA4 systems, not code execution or privilege escalation.

Why it matters to the business

Systems using affected Linux kernels with AMD RDNA4 GPUs may crash when the amdgpu driver is loaded, disrupting workstations, GPU compute nodes, graphics workloads, or systems that depend on the AMDGPU driver. Because exploitation requires a specific hardware and kernel configuration and there is no known public exploitation or KEV listing, broad internet-scale risk is low; however, affected environments can experience service interruption, failed boots into graphical mode, or loss of GPU availability after kernel/module changes.

How an attack unfolds

An attacker would need local influence over a system that has affected AMD RDNA4 hardware, an affected Linux kernel, and CONFIG_DRM_DEBUG_MM enabled. The attacker then causes the amdgpu driver to initialize, for example by loading the amdgpu module, triggering device probing, or rebooting into a configuration where the driver autoloads. During initialization, the driver attempts to register zero-sized on-chip memory resources for GDS, GWS, or OA. That zero-sized range reaches drm_mm_init(), which trips the debug assertion and crashes the kernel. In most production kernels where CONFIG_DRM_DEBUG_MM is not enabled, the described assertion path is not expected to trigger, which limits exploitability.

How to fix it

Apply a Linux kernel update that includes the AMDGPU fix for zero-sized on-chip resource initialization on RDNA4 hardware, specifically the change that returns successfully from amdgpu_ttm_init_on_chip() when size_in_page is zero and skips TTM resource manager registration for absent resources. If vendor fixed package versions are available from the operating system distributor, upgrade to those packages rather than manually patching. Where immediate patching is not possible, mitigations include avoiding kernels built with CONFIG_DRM_DEBUG_MM on affected production systems, preventing untrusted users from loading kernel modules, restricting access to reboot/module-management capabilities, and temporarily pinning to a known-good kernel or driver package.

How to confirm the fix worked

Confirm the running kernel or vendor kernel package includes the upstream AMDGPU fix associated with commit 5719ce5865279cad4fd5f01011fe037168503f2d or an equivalent backport. Validate that RDNA4 systems can load the amdgpu module without a kernel oops or panic. Check the kernel build configuration for CONFIG_DRM_DEBUG_MM; systems without that option are less exposed to the assertion-triggered crash, but should still receive the logic fix. Review dmesg or journalctl -k after boot or after modprobe amdgpu and confirm there are no traces involving DRM_MM_BUG_ON, drm_mm_init, ttm_range_man_init, or amdgpu_ttm_init_on_chip failures.

Typical attack path

1. Identify a Linux system with AMD RDNA4/GFX12 GPU hardware and an affected AMDGPU driver version.
2. Confirm or assume the kernel was built with CONFIG_DRM_DEBUG_MM enabled.
3. Obtain local ability to trigger GPU driver probing or module loading, such as invoking modprobe amdgpu or causing the device to initialize during boot.
4. Trigger AMDGPU initialization.
5. The driver attempts to initialize absent zero-sized GDS, GWS, or OA resources.
6. drm_mm_init() receives a zero-sized range and DRM_MM_BUG_ON() fires.
7. The kernel crashes, causing denial of service or preventing successful GPU driver initialization.

How to detect it

To determine whether this condition has already occurred, review kernel logs, boot logs, crash dumps, and system journal entries for crashes during amdgpu initialization. Useful sources include dmesg output, journalctl -k, /var/log/kern.log, /var/log/messages, pstore records under /sys/fs/pstore, kdump/vmcore artifacts, and distribution-specific crash reports. Focus on events around boot, GPU driver probing, or modprobe amdgpu. Look for call traces containing drm_mm_init(), DRM_MM_BUG_ON(), ttm_range_man_init(), amdgpu_ttm_init_on_chip(), amdgpu_ttm_init(), or gfx_v12_0 initialization. Because this is a denial-of-service flaw and not known to provide code execution, detection should focus on evidence of kernel assertion failures, panics, oops reports, repeated failed boots, or GPU driver load failures rather than persistence artifacts or network indicators.

• DRM_MM_BUG_ON
• drm_mm_init
• ttm_range_man_init
• amdgpu_ttm_init_on_chip
• amdgpu_ttm_init
• gfx_v12_0
• modprobe amdgpu
• amdgpu: probe
• kernel BUG
• Oops:
• Kernel panic
• CONFIG_DRM_DEBUG_MM
• /sys/fs/pstore
• /var/log/kern.log
• /var/log/messages

What your security team should do

• Prioritize patching Linux systems with AMD RDNA4/GFX12 GPUs, especially graphics workstations, GPU compute nodes, and systems running debug or custom kernels.
• Inventory kernels built with CONFIG_DRM_DEBUG_MM enabled and treat those as higher risk for this issue.
• Update through the operating system vendor’s kernel packages when available, ensuring the AMDGPU zero-sized resource initialization fix is included.
• Restrict module loading and kernel-management privileges to trusted administrators only.
• Monitor for kernel oops, panic, or failed amdgpu module initialization events on RDNA4 systems.
• If crashes are observed, preserve kernel logs and crash dumps before rebooting or changing kernels to support root-cause analysis.
• For production systems, avoid debug DRM memory-manager kernel configurations unless they are specifically required for diagnostics.