CVE-2026-43237

What it actually does

This is a local use-after-free/refcounting flaw in the Linux kernel AMDGPU DRM driver. The vulnerable code path is in GPU virtual address mapping management, specifically around amdgpu_gem_va_ioctl, amdgpu_gem_va_update_vm, VM timeline sync objects, and dma_fence reference handling. A stale or already freed dma_fence can be reused during GPU timeline updates, causing refcount underflow, invalid memory access, page faults in interrupt context, and kernel panic. Because the CVSS vector is local, low complexity, and requires low privileges, exploitation generally requires an attacker to already have local code execution as an unprivileged or minimally privileged user on a system with the vulnerable AMDGPU driver exposed. The rated impact includes confidentiality, integrity, and availability risk, although the most directly evidenced impact from the advisory is denial of service through kernel crash.

Why it matters to the business

Systems using affected Linux kernels with AMD GPU hardware or the AMDGPU driver may be vulnerable to local crashes and potential kernel-level compromise. In practical operational terms, a local user, compromised workload, or malicious application could destabilize workstations, GPU compute nodes, VDI hosts, rendering systems, or servers that expose AMDGPU device access. This can interrupt user sessions, jobs, graphics workloads, and GPU-accelerated services. The vulnerability is not listed in CISA KEV, is not known to be used in ransomware campaigns, has no known public exploit maturity, and has a very low EPSS score, so broad internet-scale exploitation is unlikely; however, local kernel bugs remain important in multi-user, containerized, desktop, and GPU-sharing environments.

How an attack unfolds

An attacker first needs local execution on a Linux system using an affected kernel and the AMDGPU DRM driver. They then interact with the DRM device interface, typically through ioctl calls reachable via AMDGPU device nodes, and exercise GPU virtual address mapping operations in a way that triggers incorrect dma_fence lifetime handling. The vulnerable path can select or reuse a fence reference at the wrong time, allowing a stale or freed fence to be exported into VM timeline synchronization. When the GPU scheduler or interrupt handler later signals that fence, the kernel may dereference freed memory, producing refcount underflow warnings, page faults, and a kernel panic. Depending on kernel configuration, allocator behavior, and exploit reliability, this may be limited to denial of service, but the vulnerability class and CVSS impact indicate that kernel memory corruption could potentially affect confidentiality or integrity as well.

How to fix it

Apply vendor-supplied Linux kernel updates that include the corrected AMDGPU fence reference handling in amdgpu_gem_va_ioctl/amdgpu_gem_va_update_vm. Because no exact fixed upstream or distribution package versions were provided, use the fixed kernel versions published by the relevant Linux distribution, hardware appliance vendor, cloud image provider, or kernel maintenance branch. Reboot into the updated kernel after installation and confirm the running kernel is the updated one, not only that the package is installed. Where immediate patching is not possible, reduce exposure by limiting local shell access, restricting access to /dev/dri/card* and /dev/dri/renderD* device nodes, disabling GPU passthrough to untrusted workloads, avoiding AMDGPU device exposure inside containers, and unloading or blacklisting the amdgpu module on systems where AMD GPU functionality is not required. These mitigations may affect graphics, display, rendering, or GPU compute functionality and should be tested before broad deployment.

How to confirm the fix worked

Validate remediation by confirming the running kernel build contains the vendor backport or upstream fix for the AMDGPU dma_fence reference handling issue. Check the running kernel with uname -a and compare it to the vendor advisory or package changelog. Confirm the amdgpu module version/build corresponds to the updated kernel, for example with modinfo amdgpu where available. Review package manager history to ensure the kernel update was installed and the host was rebooted into that kernel. For exposure validation, identify systems with AMDGPU loaded using lsmod, modprobe status, lspci GPU inventory, or /sys/module/amdgpu presence. Confirm whether local users or workloads can access /dev/dri/card* or /dev/dri/renderD* device nodes. After patching, monitor dmesg, journalctl -k, and crash/panic logs for recurrence of refcount underflow, dma_fence, amdgpu_gem_va_ioctl, or GPU scheduler crash signatures.

Typical attack path

1. Gain local code execution on a Linux host that uses an affected kernel and has the AMDGPU DRM driver loaded or accessible.
2. Confirm access to AMDGPU DRM device interfaces, such as render or card device nodes under /dev/dri/.
3. Issue crafted or high-frequency DRM/AMDGPU ioctl operations involving GPU virtual address mapping and VM timeline synchronization.
4. Trigger incorrect dma_fence reference handling, causing a stale or freed fence to remain associated with GPU timeline updates.
5. Wait for GPU scheduler or interrupt processing to signal the invalid fence.
6. Cause kernel warnings, page fault in kernel or interrupt context, and potentially a full kernel panic or system crash.
7. If attempting deeper exploitation, try to shape kernel memory reuse around the freed dma_fence object before it is signaled.

How to detect it

To determine whether this issue was already triggered or exploited, search kernel logs, persistent journald records, syslog, dmesg archives, crash dumps, kdump/vmcore data, and monitoring alerts for the provided crash signature. Key artifacts include refcount underflow warnings, use-after-free messages, page faults near dma_fence signaling, call traces containing amdgpu_gem_va_ioctl, amdgpu_fence_process, amdgpu_irq_handler, drm_sched_job_done, or gpu_sched, and kernel panic messages following AMDGPU interrupt processing. On systems with auditd or eBPF telemetry, review process activity that opened /dev/dri/card* or /dev/dri/renderD* and issued heavy ioctl activity shortly before the crash. In containerized or shared GPU environments, correlate crash time with containers, user sessions, graphics applications, compute jobs, browser/GPU sandbox processes, or test programs that had access to DRM render nodes. Because the known evidence is a kernel crash signature rather than a stable malware artifact, absence of these strings does not prove non-exploitation, especially if volatile dmesg logs were lost after reboot.

• refcount_t: underflow; use-after-free.
• WARNING: CPU:
• refcount_warn_saturate
• amdgpu_gem_va_ioctl
• __pfx_amdgpu_gem_va_ioctl
• amdgpu_gem_va_ioctl+0x6ea/0x740 [amdgpu]
• drm_ioctl_kernel
• drm_ioctl
• amdgpu_drm_ioctl
• __x64_sys_ioctl
• BUG: unable to handle page fault for address:
• dma_fence_signal_timestamp_locked
• dma_fence_signal
• drm_sched_job_done
• amdgpu_fence_process
• sdma_v4_0_process_trap_irq
• amdgpu_irq_dispatch
• amdgpu_ih_process
• amdgpu_irq_handler
• Kernel panic - not syncing: Fatal exception in interrupt
• /dev/dri/card
• /dev/dri/renderD
• /sys/module/amdgpu

What your security team should do

• Prioritize patching Linux workstations, GPU compute systems, VDI hosts, shared development servers, and container hosts where untrusted or semi-trusted users can access AMDGPU devices.
• Inventory hosts with the amdgpu kernel module loaded and AMD GPU hardware present; prioritize those with /dev/dri device nodes accessible to non-root users or containers.
• Apply the relevant distribution or vendor kernel update and reboot affected systems into the fixed kernel.
• Temporarily restrict access to /dev/dri/card* and /dev/dri/renderD* for untrusted users and workloads until patching is complete.
• Avoid passing AMDGPU devices into untrusted containers, virtual machines, CI jobs, browser sandboxes, or shared GPU workloads unless the host kernel is fixed.
• If AMD GPU functionality is not required, consider unloading or blacklisting the amdgpu module as a temporary mitigation.
• Add monitoring for kernel crash signatures involving refcount underflow, use-after-free, dma_fence, amdgpu_gem_va_ioctl, drm_sched_job_done, and amdgpu_fence_process.
• Review recent kernel panic, kdump, journald, syslog, and dmesg records for signs that the issue has already been triggered.
• Treat repeated local crashes with these signatures on shared systems as suspicious and investigate the triggering user, process, container, or workload.
• Track vendor advisories because no exact fixed package versions were provided in the input and fixes may arrive as distribution-specific backports rather than obvious upstream version jumps.