CVE-2026-68105

What it actually does

This is a Linux kernel amdgpu driver denial-of-service flaw. During amdgpu driver initialization, if MES initialization fails, the driver can incorrectly treat the KIQ ring as ready even though KIQ is owned by MES on affected ASICs. Cleanup then follows a path that attempts GPU TLB/GART teardown operations through an invalid or uninitialized ring, leading to a NULL pointer dereference in the amdgpu kernel module and a kernel panic. The practical technical result is system crash during driver load or GPU initialization failure handling, rather than a clean driver probe failure.

Why it matters to the business

Systems using affected AMD GPU hardware with vulnerable Linux kernels may crash during boot, driver loading, GPU initialization, or recovery from driver initialization failures. For workstations, GPU compute nodes, VDI hosts, rendering systems, or servers that rely on AMD GPUs, this can cause downtime, failed reboots, interrupted workloads, and reduced availability. The issue was published recently and is not currently listed in CISA KEV, has no known public exploit maturity in the provided data, and is primarily an availability risk rather than a data theft or privilege escalation issue.

How an attack unfolds

An attacker would need a way to cause the vulnerable amdgpu driver to load or reinitialize under conditions where MES initialization fails. In most deployments, loading or unloading kernel modules, manipulating PCI device binding, or forcing GPU driver reprobe requires local administrative privileges or equivalent control over the host. If those conditions are met, the attacker can trigger amdgpu initialization, induce or rely on a MES initialization failure, and cause the driver cleanup path to execute while the KIQ ring is falsely marked usable. The kernel then dereferences a NULL pointer in the amdgpu path and panics, taking the host offline. Remote exploitation is not indicated by the provided information unless an exposed management plane or workload orchestration path gives an attacker the ability to manipulate host GPU driver state.

How to fix it

Apply the vendor or Linux distribution kernel update that includes the upstream amdgpu fix for commit 4623b958dd6da0f4c3026afdf330626a09ecb0f0 or its stable-kernel backport. Because no exact affected product list or fixed package versions were provided, use distribution advisories and kernel changelogs to identify the first fixed kernel for each maintained branch. Reboot into the fixed kernel after installation. If immediate patching is not possible, reduce exposure by avoiding unnecessary amdgpu module reloads, restricting root and hardware-management access, disabling untrusted local users from GPU-capable systems, and, where operationally acceptable, preventing the amdgpu module from loading on systems that do not require AMD GPU functionality. These mitigations reduce triggerability but do not correct the kernel defect.

How to confirm the fix worked

Confirm that systems are running a kernel build that contains the amdgpu fix or a downstream backport. Validate by checking the installed/running kernel version against the relevant distribution security advisory, then rebooting and confirming the fixed kernel is active with standard OS tooling. Review kernel changelogs or package metadata for the amdgpu MES/KIQ initialization failure fix or the upstream commit reference. On representative AMD GPU systems, confirm that amdgpu loads cleanly and that no kernel panic, NULL pointer dereference, or amdgpu initialization cleanup crash appears in dmesg, journalctl, or persistent kernel logs. Where kernel live patching is used, verify that the live patch explicitly covers this amdgpu code path; otherwise plan a full kernel update and reboot.

Typical attack path

1. Gain local administrative privileges or equivalent control over a Linux host using AMD GPU hardware and the vulnerable amdgpu driver.
2. Trigger amdgpu driver load, reprobe, device bind/unbind, or a condition that causes GPU driver initialization to fail.
3. Cause or wait for MES initialization failure during driver load.
4. The driver incorrectly treats the KIQ ring as ready during cleanup.
5. The amdgpu cleanup path attempts GPU memory-management operations through invalid state.
6. The kernel hits a NULL pointer dereference in the amdgpu module and panics, causing denial of service.

How to detect it

Look for evidence of prior crashes or attempted triggering in kernel and system logs. Relevant sources include dmesg output, systemd journal kernel logs, /var/log/kern.log, /var/log/messages, /var/log/syslog, persistent pstore/ramoops logs, kdump/vmcore metadata, crash reports, and fleet telemetry for unexpected reboots. Search for amdgpu driver load failures followed by NULL pointer dereference, kernel panic, or call traces containing gfx_v12_1_wait_reg_mem, amdgpu_gmc_flush_gpu_tlb, amdgpu_gart_unbind, amdgpu_device_fini_hw, amdgpu_driver_load_kms, or amdgpu_pci_probe. Also review audit logs or administrative command histories for suspicious or repeated module operations such as modprobe, rmmod, insmod, driver bind/unbind, or PCI device reset activity involving amdgpu shortly before a crash. There are no known threat actors, ransomware usage, or confirmed exploitation campaigns in the provided data, so detection should focus on crash artifacts and local administrative actions that preceded them.

• BUG: kernel NULL pointer dereference, address: 0000000000000000
• RIP: 0010:gfx_v12_1_wait_reg_mem
• gfx_v12_1_ring_emit_reg_write_reg_wait
• amdgpu_gmc_fw_reg_write_reg_wait
• amdgpu_gmc_flush_gpu_tlb
• amdgpu_gart_invalidate_tlb
• amdgpu_gart_unbind
• amdgpu_ttm_backend_unbind
• amdgpu_ttm_tt_unpopulate
• amdgpu_bo_free_kernel
• amdgpu_ih_ring_fini
• amdgpu_irq_fini_hw
• amdgpu_device_fini_hw
• amdgpu_driver_load_kms
• amdgpu_pci_probe
• pci_device_probe
• do_init_module
• __se_sys_finit_module
• amdgpu
• amdttm
• kernel NULL pointer dereference
• Kernel panic
• MES init fails
• KIQ ring

What your security team should do

• Prioritize patching Linux systems with AMD GPUs that provide production GPU compute, VDI, rendering, desktop, or other availability-sensitive services.
• Inventory systems loading the amdgpu kernel module and map them to kernel package versions and distribution advisories.
• Restrict local administrative access, kernel module loading, PCI device rebinding, and GPU management operations to trusted administrators only.
• Monitor kernel logs for amdgpu initialization failures, MES failures, KIQ-related errors, NULL pointer dereferences, and kernel panics until patched.
• For high-availability GPU workloads, schedule controlled reboots into fixed kernels and drain workloads before maintenance to avoid unplanned outage.
• If patching must be delayed, consider temporarily disabling amdgpu on systems where AMD GPU functionality is not required.
• Because this is newly published but not KEV-listed and has no known exploit maturity in the provided data, treat it as a targeted availability hardening item rather than an active mass-exploitation emergency.