CVE-2026-46311

What it actually does

This is a local Linux kernel race condition in the AMDGPU DRM user queue code. During queue creation, the kernel can access stale write-pointer mapping data if the write-pointer buffer object is unmapped while queue setup is still in progress and a different buffer object is mapped at the same virtual address. The fix ensures both the VM root buffer object and write-pointer object are locked together via drm_exec before accessing mapping data. Without the fix, a local authenticated user with access to the AMDGPU DRM device may be able to trigger memory corruption or misuse of an unintended buffer object, potentially leading to kernel privilege escalation, information disclosure, or denial of service.

Why it matters to the business

Systems using affected Linux kernels with AMDGPU support may allow a local user or compromised low-privilege process to escalate privileges to the operating-system kernel level. The operational risk is highest on shared Linux workstations, GPU-enabled development systems, rendering nodes, AI/ML hosts, virtual desktop infrastructure, and multi-user compute environments. The vulnerability is not known to be exploited in the wild, is not listed in CISA KEV, and has a low current EPSS score, but the CVSS impact is high because successful exploitation can compromise host confidentiality, integrity, and availability.

How an attack unfolds

An attacker first needs local code execution with sufficient permission to interact with the AMDGPU DRM device, commonly through access to /dev/dri/card* or /dev/dri/renderD*. The attacker then repeatedly races AMDGPU user queue creation against unmapping or remapping of the write-pointer buffer object. By causing the original write-pointer mapping to become stale while another buffer object is placed at the same address, the attacker attempts to make the kernel operate on attacker-influenced or unintended mapping data. If the race is won reliably, the result may be kernel memory corruption, a controlled crash, disclosure of sensitive kernel memory, or elevation from a regular local account to root/kernel privileges. Exploitation is local and requires timing control, but no user interaction is required once the attacker can run code on the host.

How to fix it

Apply a Linux kernel update that includes the upstream AMDGPU user queue locking fix for stale write-pointer mappings, associated with commit 1fc6c8ab45dbee096469c08c13f6099d57a52d6c or its distribution backport. Because no package-specific fixed versions were provided, use the latest security-supported kernel from the operating-system vendor and confirm the vendor advisory explicitly includes this AMDGPU DRM fix. Reboot systems after installing the updated kernel. Where immediate patching is not possible, reduce exposure by restricting local shell access, limiting access to /dev/dri/card* and /dev/dri/renderD* to trusted users only, disabling unneeded AMDGPU hardware acceleration, removing affected GPU nodes from multi-user pools, or booting a kernel configuration without the vulnerable AMDGPU user queue functionality if operationally feasible.

How to confirm the fix worked

Confirm the running kernel version is the updated vendor kernel, not only that the package is installed. Validate with uname -a, package manager history, and vendor advisory mapping. If building from source, confirm the AMDGPU DRM code contains the fix that takes both the VM root buffer object and write-pointer object locks through drm_exec before accessing mapping data. Check that hosts were rebooted into the fixed kernel after patch installation. For exposure validation, inventory systems with loaded amdgpu modules, AMD GPU hardware, and accessible /dev/dri device nodes. Confirm untrusted users cannot access DRM render or card devices unless required. Regression-test GPU workloads after patching because the fix is in kernel GPU queue-management code.

Typical attack path

1. Obtain local code execution on a Linux system using an affected kernel with AMDGPU enabled.
2. Confirm access to AMDGPU DRM device nodes such as /dev/dri/card* or /dev/dri/renderD*.
3. Create AMDGPU user queues while manipulating the write-pointer buffer object mapping.
4. Race queue creation against unmapping and remapping so that another buffer object occupies the same virtual address.
5. Trigger stale mapping access inside the kernel AMDGPU user queue path.
6. Use the resulting memory corruption or invalid object access to crash the kernel, leak data, or escalate privileges.

How to detect it

Look for evidence of local exploitation attempts rather than network indicators, because this is a local kernel vulnerability. Useful sources include kernel logs, journalctl, dmesg, auditd, EDR process telemetry, GPU driver logs, package update logs, and file access events for DRM device nodes. Search for repeated access to /dev/dri/card* or /dev/dri/renderD* by unusual users or processes, especially followed by kernel warnings, general protection faults, NULL pointer dereferences, GPU VM faults, amdgpu ring resets, GPU hangs, or unexpected reboots. On systems with auditd, review open/ioctl activity against DRM devices by non-graphics workloads. Successful privilege escalation may leave no reliable AMDGPU-specific artifact, so correlate suspicious DRM device activity with new root processes, setuid file creation, kernel oops events, abnormal account changes, or unexplained service restarts. If threat hunting after suspected exploitation, collect volatile logs quickly because kernel crash evidence may be lost after reboot unless persistent journaling or crash dumps are enabled.

• /dev/dri/card
• /dev/dri/renderD
• amdgpu
• amdgpu_userq
• drm_exec
• GPU fault detected
• ring gfx timeout
• ring compute timeout
• amdgpu: GPU reset begin
• amdgpu: GPU reset succeeded
• BUG: kernel NULL pointer dereference
• general protection fault
• kernel BUG at
• Oops:
• WARNING: CPU:

What your security team should do

• Prioritize patching Linux systems with AMDGPU enabled in shared, multi-user, GPU compute, VDI, rendering, developer, and AI/ML environments.
• Reboot after kernel updates and verify the active kernel includes the AMDGPU stale write-pointer mapping fix.
• Inventory systems where the amdgpu kernel module is loaded and /dev/dri device nodes are accessible to non-administrative users.
• Temporarily restrict DRM device access to trusted groups until patching is complete.
• Monitor for kernel crashes, GPU resets, and suspicious local activity involving DRM device nodes on unpatched systems.
• Treat exploitation as potential full host compromise because the vulnerability can affect kernel confidentiality, integrity, and availability.
• Because this is not currently KEV-listed and has low EPSS, use risk-based scheduling, but do not defer patching on shared GPU-enabled Linux hosts.