CVE-2026-68105 Overview
CVE-2026-68105 is a NULL pointer dereference vulnerability in the Linux kernel's amdgpu Direct Rendering Manager (DRM) driver. The flaw occurs when Micro Engine Scheduler (MES) initialization fails during driver load. On Application-Specific Integrated Circuits (ASICs) that use MES, the Kernel Interface Queue (KIQ) ring is owned by MES but is falsely marked as ready during a failed init path. Subsequent cleanup operations dereference uninitialized structures and trigger a kernel panic in gfx_v12_1_wait_reg_mem. The upstream fix has been merged and cherry-picked to stable branches.
Critical Impact
A failed amdgpu driver load path can crash the kernel via a NULL pointer dereference, resulting in a denial of service on affected systems using AMD GPUs with MES-based scheduling.
Affected Products
- Linux kernel builds containing the amdgpu DRM driver with MES support
- Systems using AMD GPUs whose KIQ ring is owned by MES (including GFX v12 class hardware)
- Distributions shipping kernels prior to the merged stable fix commits
Discovery Timeline
- 2026-08-10 - CVE-2026-68105 published to the National Vulnerability Database (NVD)
- 2026-08-13 - Last updated in the NVD database
Technical Details for CVE-2026-68105
Vulnerability Analysis
The defect resides in the amdgpu driver initialization path. When MES initialization fails during driver load, the driver proceeds through error cleanup while the KIQ ring remains flagged as ready. On ASICs where MES owns the KIQ, this readiness flag is misleading because the ring structures backing the queue were never fully initialized.
During teardown, amdgpu_device_fini_hw invokes graphics memory controller (GMC) TLB flush routines that dispatch register-write-register-wait operations through the KIQ ring. The call chain reaches gfx_v12_1_wait_reg_mem, which dereferences a NULL pointer at address 0x0000000000000000 and panics the kernel. The reported call trace includes amdgpu_gmc_flush_gpu_tlb, amdgpu_gart_invalidate_tlb, amdgpu_gart_unbind, and amdgpu_ttm_backend_unbind before reaching the faulting instruction.
Root Cause
The KIQ ring readiness state is not correctly reconciled with MES initialization failure. Cleanup code assumes the ring is usable when its ready flag is set, but that flag can be true even when MES ownership of the ring has not been established. This is a driver-level state-tracking error that manifests as a NULL pointer dereference [CWE-476] during error handling.
Attack Vector
The issue is triggered by a driver load failure rather than an authenticated remote request. Any condition that causes MES init to fail during amdgpu_pci_probe and subsequent amdgpu_driver_load_kms invocation will drive the code into the faulting cleanup path. Consequences are limited to local denial of service through a kernel panic on the affected host. There is no evidence of remote exploitation and the vulnerability is not listed in the CISA Known Exploited Vulnerabilities catalog.
The vulnerability manifests during error-path teardown in the DRM subsystem. See the upstream commits linked in the Kernel Security Update and Kernel Commit Change Log for the code-level fix.
Detection Methods for CVE-2026-68105
Indicators of Compromise
- Kernel panic messages referencing BUG: kernel NULL pointer dereference, address: 0000000000000000 with RIP pointing to gfx_v12_1_wait_reg_mem+0x5a/0x1f0 [amdgpu]
- Call traces containing amdgpu_driver_load_kms, amdgpu_device_fini_hw, and amdgpu_gmc_flush_gpu_tlb during boot or module load
- dmesg entries indicating MES initialization failure immediately prior to a panic
Detection Strategies
- Parse /var/log/kern.log, journalctl -k, and crash dumps for the specific RIP and stack frames listed above to identify affected hosts
- Correlate amdgpu module load failures with subsequent unplanned reboots across fleets
- Track kernel version and amdgpu driver revision inventory against the fixed stable commit hashes 5bc93f907bad and a279bd143b3c
Monitoring Recommendations
- Alert on unexpected kernel panics on workstations and servers running AMD GPUs with GFX v12 hardware
- Monitor boot-time reliability metrics for hosts after kernel or GPU firmware updates
- Ingest kernel logs into a centralized logging pipeline to enable pattern detection across the fleet
How to Mitigate CVE-2026-68105
Immediate Actions Required
- Apply the upstream stable kernel patches referenced in commits 5bc93f907bad7e076d814664dfab8fc230efca3d and a279bd143b3c184358b658e43a057e31ee8c4de5 as soon as vendor packages are available
- Track your Linux distribution's security advisories and update to a kernel release that incorporates the fix
- Prioritize patching hosts with AMD GPUs that use MES-scheduled GFX v12 hardware
Patch Information
The fix has been merged upstream and cherry-picked from commit 4623b958dd6da0f4c3026afdf330626a09ecb0f0. It corrects the KIQ ring readiness state so that error cleanup does not attempt to use an uninitialized ring when MES init fails. Refer to the Kernel Security Update and Kernel Commit Change Log for details.
Workarounds
- Where patching is not immediately possible, avoid conditions that cause MES initialization to fail, such as mismatched GPU firmware versions
- Ensure GPU firmware (amdgpu microcode) is updated to a version compatible with the running kernel
- On systems where the AMD GPU is not required, blacklist the amdgpu module to prevent the faulting load path from executing
# Example: blacklist the amdgpu module until the kernel is patched
echo "blacklist amdgpu" | sudo tee /etc/modprobe.d/blacklist-amdgpu.conf
sudo update-initramfs -u
# Verify the running kernel version and confirm the fix is present after update
uname -r
Disclaimer: This content was generated using AI. While we strive for accuracy, please verify critical information with official sources.
