CVE-2026-46311: Linux Kernel Privilege Escalation Flaw

CVE-2026-46311 Overview

CVE-2026-46311 is a Linux kernel vulnerability in the AMD GPU (amdgpu) driver's user queue (userq) subsystem. The flaw involves access to a stale write pointer (wptr) mapping during queue creation. The fix introduces drm_exec to acquire both the virtual memory (VM) root buffer object (bo) lock and the wptr_obj bo lock when accessing mapping data. Without proper locking, a race condition allows unmapping of the wptr_obj while a queue creation operation is in progress, enabling a different buffer object to be substituted at the same address.

Critical Impact

A local attacker with GPU access can exploit the race condition to substitute buffer objects during user queue creation, potentially leading to memory corruption in kernel space.

Affected Products

• Linux kernel amdgpu driver (user queue subsystem)
• Systems with AMD GPUs using the upstream drm/amdgpu driver
• Kernel versions prior to commits 336a9186f3a4 and 6da7b1242da4

Discovery Timeline

• 2026-06-08 - CVE-2026-46311 published to NVD
• 2026-06-08 - Last updated in NVD database

Technical Details for CVE-2026-46311

Vulnerability Analysis

The vulnerability resides in the amdgpu user queue creation path. User queues allow userspace clients to submit work directly to the GPU, requiring the kernel to map a write pointer buffer object (wptr_obj) used by the GPU to track queue progress. The original code did not hold both the VM root bo lock and the wptr_obj bo lock simultaneously when accessing the mapping data. This created a window where the wptr_obj could be unmapped concurrently with queue creation. An attacker can race the unmap operation against queue creation and place a different buffer object at the same virtual address. The kernel then operates on stale mapping metadata pointing to attacker-controlled memory.

Root Cause

The root cause is improper synchronization during concurrent access to GPU virtual memory mappings, classified as a race condition. The queue creation flow accessed mapping data without holding the locks for both the VM root buffer object and the wptr_obj buffer object. The fix uses drm_exec, the DRM execution context API, to atomically acquire both locks before accessing mapping data.

Attack Vector

Exploitation requires local access with permission to interact with the amdgpu DRM device, typically through /dev/dri/renderD* nodes. An attacker triggers user queue creation in one thread while concurrently unmapping the wptr_obj and mapping a different buffer object at the same GPU virtual address. Winning the race causes the kernel to associate queue state with attacker-controlled memory. The vulnerability mechanism is described in the upstream commits referenced below; no public exploit code is available.

See the upstream fix commit 336a9186f3a4 and stable backport commit 6da7b1242da4 for technical details.

Detection Methods for CVE-2026-46311

Indicators of Compromise

• Unexpected amdgpu kernel log entries referencing wptr_obj mapping failures or invalid buffer object references
• Kernel oops or general protection faults originating in amdgpu_userq_* functions
• Processes repeatedly creating user queues and unmapping wptr buffer objects in rapid succession

Detection Strategies

• Audit kernel versions across Linux endpoints with AMD GPUs to identify hosts missing the patch commits 336a9186f3a4 and 6da7b1242da4
• Monitor dmesg and /var/log/kern.log for amdgpu warnings, BUG reports, or KASAN reports involving user queue code paths
• Track unprivileged processes invoking DRM_IOCTL_AMDGPU_USERQ ioctls at high frequency from non-graphical workloads

Monitoring Recommendations

• Enable kernel address sanitizer (KASAN) on test systems to surface use-after-free conditions in the amdgpu driver
• Collect kernel crash dumps and forward them to a centralized log analysis platform for correlation
• Establish a baseline of expected DRM ioctl activity per user and alert on deviations

How to Mitigate CVE-2026-46311

Immediate Actions Required

• Apply the upstream Linux kernel patches from commits 336a9186f3a4b65bbd865d93936605ac8a1a3991 and 6da7b1242da4455b11c24ce667d1cab1a348c8ea
• Update to a distribution kernel that includes the backported fix once available from your Linux vendor
• Restrict access to /dev/dri/renderD* device nodes to trusted users only on multi-tenant hosts

Patch Information

The fix is upstream in the Linux kernel drm/amdgpu/userq subsystem. It modifies the queue creation path to use drm_exec for acquiring both the VM root bo lock and the wptr_obj bo lock before accessing mapping data. Refer to the Kernel Git commit 336a9186f3a4 for the mainline fix and the stable tree backport 6da7b1242da4.

Workarounds

• Unload the amdgpu user queue functionality where supported, or disable user queues via kernel boot parameters if exposed by the distribution
• Restrict DRM render node permissions using udev rules so only trusted groups can open /dev/dri/renderD*
• Use mandatory access control (SELinux, AppArmor) policies to confine processes that interact with the GPU

# Configuration example: restrict DRM render node access via udev
# /etc/udev/rules.d/99-drm-render.rules
SUBSYSTEM=="drm", KERNEL=="renderD*", GROUP="render", MODE="0660"

# Verify current kernel version against patched commits
uname -r
grep -E 'amdgpu_userq|drm_exec' /proc/kallsyms | head