CVE-2026-68105 in Linux
Summary
by MITRE • 08/10/2026
In the Linux kernel, the following vulnerability has been resolved:
drm/amdgpu: Fix kernel panic during driver load failure
Avoid kernel panic if MES init fails during driver load. The KIQ ring is falsely marked as ready as ASICs that use MES, KIQ is owned by MES.
BUG: kernel NULL pointer dereference, address: 0000000000000000 RIP: 0010:gfx_v12_1_wait_reg_mem+0x5a/0x1f0 [amdgpu]
Call Trace: gfx_v12_1_ring_emit_reg_write_reg_wait+0x1f/0x30 [amdgpu]
amdgpu_gmc_fw_reg_write_reg_wait+0xb2/0x190 [amdgpu]
amdgpu_gmc_flush_gpu_tlb+0x1cc/0x230 [amdgpu]
amdgpu_gart_invalidate_tlb+0x81/0xa0 [amdgpu]
amdgpu_gart_unbind+0x72/0x90 [amdgpu]
amdgpu_ttm_backend_unbind+0xa4/0xb0 [amdgpu]
amdgpu_ttm_tt_unpopulate+0x13/0xd0 [amdgpu]
amdttm_tt_unpopulate+0x29/0x70 [amdttm]
ttm_bo_put+0x1eb/0x360 [amdttm]
amdgpu_bo_free_kernel+0xf9/0x1f0 [amdgpu]
amdgpu_ih_ring_fini+0x5a/0x90 [amdgpu]
amdgpu_irq_fini_hw+0x58/0x80 [amdgpu]
amdgpu_device_fini_hw+0x4e0/0x5b0 [amdgpu]
amdgpu_driver_load_kms+0x60/0xa0 [amdgpu]
amdgpu_pci_probe+0x28e/0x6d0 [amdgpu]
pci_device_probe+0x19f/0x220 really_probe+0x1ed/0x340 driver_probe_device+0x1e/0x80 __driver_attach+0xd3/0x1a0 bus_for_each_dev+0x68/0xa0 bus_add_driver+0x19f/0x270 driver_register+0x5d/0xf0 do_one_initcall+0xac/0x200 do_init_module+0x1ec/0x280 __se_sys_finit_module+0x2de/0x310 do_syscall_64+0x6a/0x250 entry_SYSCALL_64_after_hwframe+0x4b/0x53
(cherry picked from commit 4623b958dd6da0f4c3026afdf330626a09ecb0f0)
If you want to get best quality of vulnerability data, you may have to visit VulDB.
Analysis
by VulDB Data Team • 08/10/2026
The vulnerability in question represents a critical kernel panic condition within the Linux drm/amdgpu driver subsystem that occurs during hardware initialization failures. This issue specifically affects AMD GPU devices utilizing the gfx_v12_1 architecture where the Multi-Engine Scheduler (MES) component interacts with the Kernel Interrupt Queue (KIQ) ring. The flaw manifests as a NULL pointer dereference when the system attempts to initialize the graphics driver components, leading to an immediate kernel panic that terminates the operating system's ability to function normally.
The technical root cause stems from improper state management within the driver initialization sequence where the KIQ ring is incorrectly marked as ready even when the MES initialization fails. This misclassification creates a cascade of failures during subsequent hardware setup operations, particularly when attempting to write register values and manage GPU memory mappings. The call stack demonstrates how the error propagates through multiple kernel subsystems including graphics memory management, interrupt handling, and ttm (texture translation manager) components before ultimately crashing the system during driver load completion.
This vulnerability directly relates to CWE-476 which addresses NULL pointer dereferences in software systems, and it aligns with ATT&CK technique T1059.003 for kernel-level exploitation and T1490 for system disruption. The impact extends beyond simple system instability as it represents a denial-of-service condition that can prevent legitimate GPU usage and potentially compromise system availability during critical operations. When triggered, the kernel panic prevents normal operation of the graphics subsystem and can affect applications requiring GPU acceleration or display functionality.
Mitigation strategies should focus on implementing proper error handling within the driver initialization sequence to prevent false state transitions and ensure graceful degradation when hardware components fail to initialize properly. System administrators should apply the patched kernel version containing the cherry-picked commit that addresses this specific issue, which corrects the conditional logic for marking KIQ ring readiness based on actual MES initialization success. Additional monitoring solutions should be implemented to detect early signs of driver load failures, and system recovery procedures should include automated fallback mechanisms for GPU-dependent services during such critical initialization errors.