CVE-2026-89828
UnknownSummary
In the Linux kernel, amdgpu_vram_mgr_init() in the drm/amdgpu driver calls drmm_cgroup_register_region() before initializing lists and the buddy allocator. On failure, an early return bypasses those initializations, and the teardown path then dereferences NULL pointers, causing a kernel panic on the module load error path.
Risk Assessment
This can cause a kernel panic (denial of service) during amdgpu module load, particularly on systems with AMD GPUs.
Recommendation
Update the Linux kernel to a version with the fix that moves drmm_cgroup_register_region() after the lists and buddy allocator are fully initialized.
Other vulnerabilities in Linux kernel (drm/amdgpu)
See all- CVE-2026-89827Low risk· EPSS 10%
In the Linux kernel, uvd_v7_0_sw_init() does not initialize the UVD decode ring for an SR-IOV VF, yet amdgpu_uvd_resume() unconditionally force-completes that ring when restoring its fence sequence. This operates on an uninitialized ring.
- CVE-2025-68230Low risk· EPSS 8%
In the Linux kernel, the drm/amdgpu driver can cause a GPU page fault after hibernation and resume in a PF passthrough environment. The partition mode is not restored on resume, leading to incorrect registers and wrong stride size when accessing the MQD BO, causing out-of-bounds access. The fix ensures gfx_v9_4_3_switch_compute_partition() is called on resume from hibernation.
Original NVD description (English source)
In the Linux kernel, the following vulnerability has been resolved: drm/amdgpu: Fix init ordering in amdgpu_vram_mgr_init() drmm_cgroup_register_region() is called before INIT_LIST_HEAD() and gpu_buddy_init() in amdgpu_vram_mgr_init(). If it fails, the function returns early and bypasses those initializations. Since adev->mman.initialized is set to true before amdgpu_vram_mgr_init() is called, a failure triggers amdgpu_ttm_fini(), which calls amdgpu_vram_mgr_fini(), which then: - Calls list_for_each_entry_safe() on reservations_pending and reserved_pages, whose list_head::next pointers are zero-initialized (NULL). The loop does not recognize them as empty and dereferences NULL. - Calls gpu_buddy_fini(), which iterates free_trees[] unconditionally via for_each_free_tree(). Since mm->free_trees is NULL (never allocated), this dereferences NULL. Both result in a kernel panic on the module load error path. Fix by moving drmm_cgroup_register_region() to after the list and buddy allocator are fully initialized, so the teardown path is safe to run.
Vulnerability data from NVD (NIST) · CISA KEV · EPSS