EUVD-2026-35141
GHSA-qm9f-7whf-hhc4
Severity by source
AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
AC:H reflects dual requirements of RDNA4 hardware plus CONFIG_DRM_DEBUG_MM; PR:N because crash fires automatically at boot without any user action.
Primary rating from NVD.
CVSS VectorNVD
CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
Lifecycle Timeline
5DescriptionNVD
In the Linux kernel, the following vulnerability has been resolved:
drm/amdgpu: fix zero-size GDS range init on RDNA4
RDNA4 (GFX 12) hardware removes the GDS, GWS, and OA on-chip memory resources. The gfx_v12_0 initialisation code correctly leaves adev->gds.gds_size, adev->gds.gws_size, and adev->gds.oa_size at zero to reflect this.
amdgpu_ttm_init() unconditionally calls amdgpu_ttm_init_on_chip() for each of these resources regardless of size. When the size is zero, amdgpu_ttm_init_on_chip() forwards the call to ttm_range_man_init(), which calls drm_mm_init(mm, 0, 0). drm_mm_init() immediately fires DRM_MM_BUG_ON(start + size <= start) -- trivially true when size is zero -- crashing the kernel during modprobe of amdgpu on an RX 9070 XT.
Guard against this by returning 0 early from amdgpu_ttm_init_on_chip() when size_in_page is zero. This skips TTM resource manager registration for hardware resources that are absent, without affecting any other GPU type.
DRM_MM_BUG_ON() only asserts if CONFIG_DRM_DEBUG_MM is enabled in the kernel config. This is apparently rarely enabled as these chips have been in the market for over a year and this issue was only reported now.
Oops-Analysis: http://oops.fenrus.org/reports/bugzilla.korg/221376/report.html (cherry picked from commit 5719ce5865279cad4fd5f01011fe037168503f2d)
AnalysisAI
Kernel panic in the Linux amdgpu DRM driver exposes systems running RDNA4 hardware (e.g., AMD RX 9070 XT) to a denial-of-service condition during driver initialization, but only when the kernel is compiled with CONFIG_DRM_DEBUG_MM enabled. The RDNA4 architecture (GFX 12) removed the GDS, GWS, and OA on-chip memory resources entirely; however, amdgpu_ttm_init() unconditionally invokes amdgpu_ttm_init_on_chip() for these resources regardless of size, ultimately calling drm_mm_init(mm, 0, 0), which triggers DRM_MM_BUG_ON and crashes the kernel at modprobe time. No public exploit exists and EPSS sits at 0.02% (7th percentile), consistent with a hardware-specific, debug-config-dependent crash rather than a remotely triggerable attack surface.
Technical ContextAI
The affected component is the amdgpu kernel module within the Linux DRM (Direct Rendering Manager) subsystem, confirmed by CPE cpe:2.3:a:linux:linux:*. The Translation Table Manager (TTM) is a memory manager for GPU on-chip resources. amdgpu_ttm_init() calls amdgpu_ttm_init_on_chip() for each of GDS (Global Data Share), GWS (Global Wave Sync), and OA (Ordered Append) memory pools. RDNA4/GFX12 removed these hardware blocks entirely, leaving their sizes at zero in the adev structure. When size is zero, the call path reaches ttm_range_man_init() then drm_mm_init(mm, 0, 0). The drm_mm allocator validates via DRM_MM_BUG_ON(start + size <= start), which is trivially true for start=0 and size=0, firing a kernel BUG() call that halts execution. This assertion is only compiled in when CONFIG_DRM_DEBUG_MM is set - an optional debug configuration flag noted in the report as 'apparently rarely enabled,' which explains why this defect went undetected for over a year of RDNA4 market availability. No CWE was formally assigned, but the root cause is an unchecked zero-size input reaching an invariant-asserting allocator - closest to CWE-20 (Improper Input Validation) within an internal API boundary.
RemediationAI
The primary fix is upgrading to a patched kernel version: 5.10.258, 5.15.209, 6.1.175, 6.6.140, 6.12.86, 6.18.27, 7.0.4, or any build from mainline at or after 7.1-rc2. The upstream fix commits are available via git.kernel.org stable branch references including https://git.kernel.org/stable/c/1f5d33e7b0a9a2a140f46e22fb52eede323c5946 and associated stable-tree commits for each branch. Ubuntu users should apply patches from USN-8489-1 or USN-8488-1. The compensating control for systems that cannot immediately upgrade is to rebuild the kernel without CONFIG_DRM_DEBUG_MM - this disables the debug assertion entirely, preventing the BUG_ON from firing, though it also removes DRM memory-manager debug diagnostics. Alternatively, blacklisting the amdgpu module (add 'blacklist amdgpu' to /etc/modprobe.d/) prevents the crash at the cost of losing GPU hardware access. Neither workaround is appropriate for production systems relying on RDNA4 GPU functionality; patching is the correct remediation.
Same technique Denial Of Service
View allShare
External POC / Exploit Code
Leaving vuln.today