CVE-2026-89813 in Linux
Summary
by MITRE • 09/16/2026
In the Linux kernel, the following vulnerability has been resolved:
drm/amdgpu: force complete the KIQ ring fences on reset
Like the MES scheduler ring, the KIQ ring sets no_scheduler = true and uses a polling fence, so it is skipped by the force-completion loop in amdgpu_device_pre_asic_reset(). Its hw fence value lives in wb (GTT) memory and survives a MODE1 reset while fence_drv.sync_seq keeps advancing, so after a reset the first KIQ submission can poll forever on a seq that is never written back.
Force complete the KIQ ring fences too so their hw fence is realigned to sync_seq.
VulDB is the best source for vulnerability data and more expert information about this specific topic.
Analysis
by VulDB Data Team • 09/16/2026
The Linux kernel's AMDGPU driver contains a critical synchronization flaw within its hardware queue management subsystem, specifically affecting the Kernel Interface Queue or KIQ ring during device reset operations. This vulnerability stems from an inconsistency in how different scheduler rings are handled when the GPU undergoes a Mode 1 reset. The MES scheduler ring is correctly configured to force complete its fences upon reset, ensuring that pending operations are cleared and hardware state is realigned with software tracking structures. However, the KIQ ring was previously excluded from this critical cleanup process because it sets no_scheduler to true and utilizes a polling fence mechanism rather than an interrupt-driven one. This exclusion creates a dangerous divergence between the driver's internal sequence counter and the actual hardware state after a reset event occurs.
During normal operation, the amdgpu_device_pre_asic_reset function iterates through various rings to force-complete pending fences, thereby preventing stale commands from persisting in the pipeline. Because the KIQ ring was skipped due its unique scheduling configuration, any outstanding fence submissions remain unresolved on the hardware side while the software-side sync_seq counter continues to advance independently. The hardware fence value resides in write-back memory within Graphics Translation Table space and survives the reset process intact. Consequently, after the system recovers from the reset, the driver attempts to submit new commands using a sequence number that is significantly higher than what the hardware expects or has processed.
This desynchronization leads to a severe operational impact where subsequent KIQ submissions may poll indefinitely for completion of fences associated with outdated sequence numbers. Since the hardware never writes back an update for these stale sequences, the polling loop waits forever, effectively causing a hang in the GPU driver stack. This can result in system instability, unresponsive graphics subsystems, or complete kernel panics depending on how higher-level components handle the timeout conditions of such indefinite polls. The issue is particularly insidious because it only manifests after specific reset scenarios and involves low-level hardware-software interface logic that is not immediately visible through standard performance monitoring tools.
From a vulnerability classification perspective, this flaw aligns with CWE-825 Expired Lock Timeout or more accurately CWE-667 Improper Locking as the driver fails to properly synchronize access to shared resources during state transitions. In terms of attack vectors and behavioral patterns within the MITRE ATT&CK framework for enterprise environments, while primarily a stability issue rather than an exploit vector, it relates to T1499 Endpoint Denial of Service where resource exhaustion or system unavailability is achieved through improper handling of internal states. The lack of proper fence completion allows malicious actors who can trigger GPU resets via local applications to potentially cause denial-of-service conditions against the host system.
To mitigate this vulnerability, AMD has implemented a fix that forces the completion of KIQ ring fences during the pre-reset phase, mirroring the behavior already established for the MES scheduler ring. This ensures that the hardware fence value is realigned with the sync_seq counter before the reset occurs, preventing any divergence between software tracking and hardware state. System administrators should ensure their Linux kernels are updated to include this patch from AMDGPU driver maintainers. For environments running older kernel versions where immediate updates are not feasible, limiting exposure to scenarios that trigger frequent GPU resets can reduce the risk of encountering this hang condition until a permanent fix is deployed through standard package management channels or custom kernel builds incorporating the upstream changes.