CVE-2026-31462

What it actually does

This is a local race condition in the Linux kernel AMDGPU DRM driver. The flaw occurs when a Process Address Space ID (PASID) is freed as a GPU-using process exits and is then immediately reused by another process while page-fault interrupts from the previous process may still be pending in the interrupt handler ring buffer. The new process can inherit or interact with stale GPU fault state associated with the reused PASID, which can trigger interrupt handling problems and lead to system instability or denial of service. The CVSS vector indicates local access is required, low attack complexity, low privileges, no user interaction, and primary impact to availability rather than confidentiality or integrity.

Why it matters to the business

Successful exploitation can crash, hang, or destabilize Linux systems using affected AMDGPU kernel driver code, especially GPU-enabled workstations, compute nodes, rendering systems, or servers running local GPU workloads. The likely business consequence is service interruption rather than data theft: failed jobs, degraded graphics or compute availability, node reboots, and operational disruption for GPU-dependent workloads. This vulnerability is not currently listed in CISA KEV, has no known ransomware association, has no reported exploit maturity, and has a very low EPSS score with no recent upward trend, so broad internet-scale exploitation is unlikely; however, shared multi-user Linux systems with AMD GPUs deserve higher priority because a low-privileged local user may be able to trigger the condition.

How an attack unfolds

An attacker first needs local code execution on a Linux system that uses the affected AMDGPU driver path. They run or script GPU workloads that rapidly create and terminate processes or GPU contexts in a way that causes PASIDs to be released and reallocated quickly. If a process exits while GPU page-fault interrupts associated with its PASID remain pending in the interrupt handler ring buffer, the allocator may immediately assign the same PASID to a new process. The new process can then encounter stale hardware or interrupt state from the prior process. By repeatedly exercising this timing window, the attacker attempts to trigger interrupt faults, GPU driver errors, hangs, or a kernel-level denial of service. There is no indication from the supplied data that this enables remote exploitation, privilege escalation, or data disclosure.

How to fix it

Apply a Linux kernel update from the operating system or distribution vendor that includes the upstream AMDGPU fix for preventing immediate PASID reuse. The fix changes PASID allocation behavior to use a cyclic allocator pattern, reducing the chance that a newly created process immediately receives the same PASID as a just-exited process with pending hardware fault state. No exact fixed package versions were provided in the input, so use vendor advisories and package changelogs for the specific distribution, kernel stream, and hardware enablement stack in use. Where immediate patching is not possible, reduce exposure by limiting local shell access on GPU-enabled systems, restricting untrusted users from running GPU workloads, isolating shared GPU compute workloads, and considering temporary disablement or removal of AMDGPU access on systems where the GPU is not operationally required. Reboot systems after kernel updates so the fixed kernel and driver are actually loaded.

How to confirm the fix worked

Confirm the running kernel version includes the vendor backport or upstream commit that prevents immediate PASID reuse in the AMDGPU driver. Validate both installed and running kernel versions, because installing a patched kernel without rebooting leaves the vulnerable driver active. Check whether the amdgpu module is loaded and whether AMD GPU hardware is present; systems without the AMDGPU driver path in use are not practically exposed to this issue. Review vendor changelogs for references to AMDGPU PASID reuse, drm/amdgpu, or the upstream fix commit. After patching and rebooting, run representative GPU workloads and monitor kernel logs for recurring amdgpu page-fault, PASID, interrupt handler, GPU reset, or hang messages. Exposure can be confirmed by identifying affected kernel builds with AMDGPU enabled; remediation can be confirmed by booting into a fixed kernel and verifying the vulnerable build is no longer running.

Typical attack path

1. Gain low-privileged local access to a Linux host with an affected AMDGPU kernel driver.
2. Confirm that AMDGPU hardware and the amdgpu kernel module are in use.
3. Run a workload that repeatedly creates GPU contexts or GPU-using processes.
4. Rapidly terminate and restart those processes to force PASID allocation and reuse.
5. Race process exit against pending GPU page-fault interrupts in the AMDGPU interrupt handler path.
6. Trigger stale PASID-related interrupt handling behavior, causing GPU driver instability, hangs, or system denial of service.

How to detect it

Evidence of exploitation is likely to be indirect because this vulnerability causes driver or system instability rather than creating a distinctive file, network beacon, or persistent artifact. Review kernel and system logs such as journald, dmesg, syslog, kern.log, crash dumps, and GPU monitoring logs for AMDGPU faults, repeated GPU resets, hangs, page-fault storms, PASID-related messages, interrupt handler errors, or unexplained reboots. Correlate those events with local user sessions, batch jobs, container workloads, or scripts that rapidly start and stop GPU-using processes shortly before the failure. On shared GPU systems, look for repeated crashes tied to the same user account, job, container image, or workload pattern. Because no public exploit maturity or named threat actor activity is reported in the supplied data, detection should emphasize anomaly correlation and forensic timeline reconstruction rather than signature-only matching. Preserve kernel crash dumps and pstore/kdump artifacts where available, as they may contain stack traces pointing to drm/amdgpu, GPUVM faults, PASID handling, interrupt handling, or GPU reset paths.

• amdgpu
• drm/amdgpu
• PASID
• pasid
• GPU fault
• GPU page fault
• page fault
• IH ring
• interrupt handler
• GPU reset
• ring gfx timeout
• amdgpu: GPU reset
• amdgpu: ring
• amdgpu: VM fault
• amdgpu: GPU fault detected
• amdgpu: IH
• dmesg
• /var/log/kern.log
• /var/log/syslog
• /var/log/messages
• /var/crash
• /sys/module/amdgpu

What your security team should do

• Inventory Linux systems with AMD GPUs and the amdgpu kernel module loaded, prioritizing shared compute, VDI, rendering, workstation, and multi-user environments.
• Patch affected systems through the appropriate Linux distribution kernel update channel and reboot into the fixed kernel.
• Prioritize systems where untrusted or semi-trusted local users can run GPU workloads, because exploitation requires local low-privileged access.
• If patching is delayed, restrict local account access and GPU device access to trusted users only, and isolate high-risk GPU workloads.
• Monitor kernel logs for amdgpu page-fault, PASID, interrupt, GPU reset, and hang events, especially when correlated with rapid process churn or suspicious local user activity.
• Do not treat this as an internet-facing remote code execution issue based on the supplied intelligence; focus response on local availability risk and GPU-enabled Linux hosts.
• Track vendor advisories for exact fixed package versions because none were provided in the input.