CVE-2026-43370

What it actually does

This is a local Linux kernel use-after-free race in the AMDGPU DRM driver. When parent and child processes share a DRM file descriptor after fork(), both can attempt to acquire the same GPU virtual-memory object at the same time. The vulnerable code used a non-atomic assignment to vm->process_info, allowing one racing path to free or replace state while another path still uses it. A local user with access to the AMDGPU DRM device can potentially trigger memory corruption in kernel context, leading to kernel crash, information disclosure, or local privilege escalation.

Why it matters to the business

Systems using the Linux kernel with the AMDGPU driver may be exposed to local privilege escalation or denial of service. The practical risk is highest on multi-user Linux workstations, GPU-enabled servers, VDI platforms, CI/build hosts, shared research/HPC systems, and container platforms that pass through /dev/dri GPU devices. Although the EPSS score is low, the issue affects kernel code and has high confidentiality, integrity, and availability impact; successful exploitation could allow a low-privileged user to take control of the host or disrupt GPU-dependent workloads.

How an attack unfolds

An attacker first needs local code execution as an unprivileged user on a Linux system where the AMDGPU DRM driver is loaded and the attacker can access the relevant /dev/dri device. The attacker opens the DRM device, creates process conditions where a parent and child share the same drm_file across fork(), and repeatedly races both processes into the AMDGPU VM acquisition path. If the race is won, stale process_info state may be used after it has been freed or replaced. Depending on kernel build, allocator behavior, and available primitives, this can manifest as a kernel crash or may be shaped into broader kernel memory corruption that supports privilege escalation. There is no indication from the provided data that this vulnerability is in CISA KEV, used in ransomware, or has mature public exploitation, but the flaw is in a privileged kernel driver path and should be treated as high impact on exposed AMDGPU systems.

How to fix it

Upgrade to a Linux kernel build that contains the AMDGPU fix replacing the non-atomic vm->process_info assignment with cmpxchg(), associated with upstream commit c7c573275ec20db05be769288a3e3bb2250ec618 or the corresponding distribution backport. Because no exact fixed package versions were provided, use the fixed kernel packages published by the operating system or appliance vendor for CVE-2026-43370 and reboot into the updated kernel. Where immediate patching is not possible, reduce exposure by restricting access to /dev/dri/card* and /dev/dri/renderD* to trusted users only, removing untrusted users from video/render groups, disabling GPU passthrough to untrusted containers or workloads, disabling or unloading the amdgpu module where AMD GPU functionality is not required, and isolating multi-user GPU systems until patched. Mitigations should be treated as temporary because the vulnerable code runs in kernel context.

How to confirm the fix worked

Confirm the running kernel is the patched vendor build, not only that packages are installed. Check uname -a and the distribution package manager for the active kernel version, then verify the kernel changelog, vendor advisory, or source package includes the AMDGPU VM acquire race fix or upstream commit c7c573275ec20db05be769288a3e3bb2250ec618. Confirm the host has rebooted after patching. On systems without AMD GPUs or without the amdgpu module loaded, exposure is lower; validate with lsmod, modinfo amdgpu, lspci, and /dev/dri device presence. Review permissions on /dev/dri/card* and /dev/dri/renderD* and ensure only intended users or workloads can access them. Avoid using exploit proof-of-concept testing in production; validation should rely on patch provenance, running-kernel checks, and access-control review.

Typical attack path

1. Gain local execution on a Linux system through a user account, compromised application, shell access, or container with GPU device access.
2. Confirm that the AMDGPU driver is present and that /dev/dri/card* or /dev/dri/renderD* is accessible.
3. Open the AMDGPU DRM device from user space.
4. Create parent/child process relationships that share the DRM file descriptor after fork().
5. Repeatedly trigger the AMDGPU VM acquisition path from both processes to win the race on vm->process_info.
6. Cause kernel memory corruption, usually resulting in a crash and potentially enabling privilege escalation if exploitation is reliable.
7. Use elevated privileges, if obtained, to disable defenses, access sensitive data, or persist on the host.

How to detect it

There is no single network indicator for this vulnerability because exploitation is local and occurs through the Linux DRM/AMDGPU device interface. To determine whether it may already have been exploited, review kernel logs, persistent journals, crash dumps, and EDR telemetry for AMDGPU-related kernel faults, use-after-free reports, suspicious crashes shortly after fork-heavy local processes access /dev/dri devices, and unexpected privilege changes following GPU driver instability. Relevant sources include /var/log/kern.log, /var/log/messages, /var/log/syslog, journalctl -k, auditd logs for /dev/dri access, Linux crash dump directories, kdump/vmcore artifacts, EDR process lineage, and container runtime logs showing GPU device mounts. Pay particular attention to unprivileged users or containers repeatedly opening /dev/dri/card* or /dev/dri/renderD*, processes that fork rapidly while holding DRM file descriptors, and kernel oops traces involving amdgpu VM code. Absence of these artifacts does not prove non-exploitation, especially if kernel logs rotated or crash dumps were not retained.

• BUG: KASAN: use-after-free
• use-after-free in amdgpu
• amdgpu_vm
• amdgpu_vm_get_task_info
• amdgpu: VM
• drm:amdgpu
• general protection fault
• kernel NULL pointer dereference
• kernel BUG at drivers/gpu/drm/amd/amdgpu
• Oops:
• /dev/dri/card
• /dev/dri/renderD
• amdgpu

What your security team should do

• Prioritize patching Linux systems that load the amdgpu driver and are multi-user, internet-adjacent via remote access, GPU-enabled for containers, or used for shared workloads.
• Reboot after kernel updates and verify the active kernel contains the AMDGPU VM acquire race fix, not just that an updated package is installed.
• Inventory hosts with AMD GPUs, loaded amdgpu modules, and accessible /dev/dri devices to identify the exposed population.
• Temporarily restrict /dev/dri access to trusted users and remove unnecessary membership in video or render groups until patching is complete.
• Review container, Kubernetes, VDI, CI, and HPC configurations for unnecessary GPU device passthrough to untrusted workloads.
• Monitor kernel logs for AMDGPU-related crashes, KASAN use-after-free reports, general protection faults, or repeated GPU VM failures that could indicate attempted triggering.
• Treat unexplained local kernel crashes on affected AMDGPU systems as potentially security relevant and preserve logs, crash dumps, and workload context for investigation.
• Because this issue is not listed as KEV and has low EPSS in the provided data, use risk-based prioritization, but do not defer patching on shared GPU hosts due to the high local impact.