CVE-2026-43318

What it actually does

This is a local race-condition flaw in the Linux kernel AMDGPU DRM driver involving dma-buf move notification and synchronization of shared buffer-object page table updates. When a buffer object is shared across processes or GPUs, one process can trigger movement or invalidation of the buffer while another GPU job is still using it. Because the driver may update GPU page tables at the wrong point in the synchronization sequence, an in-flight GPU operation can reference stale or incorrect mappings, leading to GPU page faults, scheduler timeouts, hangs, or kernel-level availability impact. The CVSS scope indicates local, low-complexity exploitation by a user with local privileges, with high availability impact and no expected direct confidentiality or integrity impact.

Why it matters to the business

Systems using AMD GPUs with affected Linux kernel versions may experience graphics stack instability, GPU hangs, display disruption, workload failure, or host degradation when local users or workloads trigger the vulnerable buffer-sharing path. The most likely operational impact is denial of service against desktops, workstations, GPU-enabled servers, VDI hosts, rendering systems, or compute environments that rely on AMDGPU. Because the issue is not in CISA KEV, has very low EPSS, and has no known public exploit maturity, broad internet-driven exploitation is unlikely; however, multi-user Linux systems and shared GPU platforms should still prioritize kernel updates because a local user or compromised workload could intentionally cause instability.

How an attack unfolds

An attacker first needs local code execution or the ability to run a workload on an affected Linux system using the AMDGPU driver. They then create or use GPU workloads that share dma-buf-backed buffer objects between processes, GPU contexts, or devices. By arranging concurrent rendering, blit, import/export, or buffer-move activity, the attacker attempts to hit the race where amdgpu_dma_buf_move_notify causes page table handling to occur while another GPU job still depends on the previous mapping. If the timing is successful, the GPU may fault on stale mappings, causing job failures, scheduler timeouts, GPU reset attempts, display server instability, or a broader denial-of-service condition. There is no indication from the provided data that this vulnerability enables remote code execution, privilege escalation, data theft, or ransomware use.

How to fix it

Upgrade to a Linux kernel version that includes the upstream AMDGPU fix for the dma-buf move-notification synchronization bug. No exact fixed version was provided in the input, so use the kernel packages supplied by the relevant Linux distribution or vendor advisory for CVE-2026-43318, and confirm that the backported patch for drm/amdgpu sync handling in amdgpu_dma_buf_move_notify is included. Where immediate patching is not possible, reduce exposure by limiting untrusted local shell access, restricting access to GPU device nodes such as /dev/dri/renderD* and /dev/dri/card*, isolating untrusted GPU workloads in separate hosts or stronger sandboxing boundaries, disabling AMDGPU access for untrusted users, and scheduling GPU-intensive multi-process workloads away from shared production systems until patched.

How to confirm the fix worked

Confirm exposure by identifying Linux hosts using AMD GPUs and the amdgpu kernel module, then verifying their installed kernel package against the distribution advisory or changelog containing the fix. Validate remediation by checking that the running kernel is the patched version after reboot, not only that the package is installed. Administrators can review kernel changelogs for references to drm/amdgpu, amdgpu_dma_buf_move_notify, dma-buf move notification, or amdgpu_vm_handle_moved synchronization. Functional validation should include running representative GPU workloads that use buffer sharing, display compositing, rendering, or compute activity and confirming there are no recurring AMDGPU page faults, GPU scheduler timeouts, display-server crashes, or GPU reset loops in kernel logs.

Typical attack path

1. Obtain local execution on a Linux system using an affected AMDGPU kernel driver.
2. Start GPU workloads that create, export, import, and share dma-buf buffer objects across processes or GPU contexts.
3. Trigger buffer movement or invalidation while another GPU job is still operating on the shared buffer.
4. Exploit the synchronization race so page table updates occur at an unsafe time relative to in-flight GPU work.
5. Cause GPU page faults, graphics scheduler timeouts, GPU resets, process crashes, display disruption, or host availability degradation.

How to detect it

To assess possible prior exploitation, review kernel, system, display, and GPU workload logs for repeated AMDGPU page faults, GPU scheduler timeouts, ring hangs, GPU reset attempts, display-server crashes, or workload failures occurring after local users ran graphics or compute jobs. Useful sources include journalctl kernel logs, /var/log/kern.log, /var/log/messages, /var/log/syslog, Xorg logs, Wayland compositor logs, container or job scheduler logs for GPU workloads, and audit records showing access to /dev/dri/card* or /dev/dri/renderD*. Focus on clusters of events involving dma-buf sharing, buffer movement, VM faults, amdgpu job timeouts, or GPU reset loops. There are no unique network indicators because exploitation is local and occurs through kernel GPU driver behavior. Detection should therefore correlate local GPU device access by a user or process with subsequent AMDGPU page faults, resets, hangs, or service disruption.

• amdgpu: GPU fault detected
• amdgpu: VM_CONTEXT
• amdgpu: ring gfx timeout
• amdgpu: ring sdma timeout
• amdgpu: ring compute timeout
• amdgpu_job_timedout
• drm_sched_job_timedout
• GPU reset begin
• GPU reset succeeded
• GPU reset failed
• amdgpu: Page fault
• amdgpu: recover vram bo from shadow
• amdgpu: failed to recover some errors
• /dev/dri/card0
• /dev/dri/renderD128
• /var/log/kern.log
• /var/log/syslog
• /var/log/messages
• /var/log/Xorg.0.log

What your security team should do

• Inventory Linux systems with AMD GPUs and the amdgpu driver loaded, prioritizing multi-user workstations, VDI, rendering, compute, and shared GPU servers.
• Patch affected systems using vendor-supplied kernel updates and reboot into the fixed kernel; verify the running kernel version after reboot.
• If patching is delayed, restrict untrusted users and workloads from accessing /dev/dri/card* and /dev/dri/renderD* devices.
• Monitor kernel logs for AMDGPU page faults, GPU job timeouts, GPU reset events, and display-server instability that coincide with local GPU workload execution.
• Treat unexplained repeated GPU hangs on shared systems as potentially deliberate denial-of-service activity, especially where untrusted users can run graphics or compute workloads.
• Because EPSS is very low and the vulnerability is not in KEV, prioritize based on local exposure and business reliance on AMDGPU availability rather than internet-facing risk.