CVE-2026-46311 Linux AMD GPU Kernel Memory Corruption Vulnerability

Technical summary

The vulnerability exists in the amdgpu userspace queue (userq) subsystem where the write-pointer object (wptr_obj) mapping was accessed without holding the necessary locks. During GPU queue creation, the kernel could reference a stale or remapped wptr_obj if an attacker unmapped the original object and allocated a different buffer object at the same virtual address. The fix involves using drm_exec to acquire both the VM root buffer object and wptr_obj buffer object locks before accessing mapping data, ensuring atomic and race-free access to the GPU command queue initialization structures.

Business impact

Organizations deploying AMD GPU-accelerated Linux systems face potential kernel compromise if local users exploit this vulnerability. Affected systems could experience unauthorized data access, privilege escalation, system crashes, or further lateral movement within the kernel. Systems used for sensitive compute workloads, machine learning inference, or multi-tenant GPU sharing are at higher risk. The vulnerability requires local access, limiting exposure in remote-only environments but posing significant risk on shared systems, workstations, and edge compute appliances.

Affected systems

All Linux kernel versions that include the vulnerable amdgpu userq code path are affected. This includes current stable and long-term support kernels with AMD GPU support enabled. The vulnerability does not affect systems without AMD GPUs or those running kernels with GPU driver support disabled. Patched kernels containing commit 1fc6c8ab45dbee096469c08c13f6099d57a52d6c or later versions are protected.

Exploitability

Exploitation requires local system access and unprivileged user execution; no authentication is needed. An attacker must manipulate GPU memory object lifecycle during queue creation, a tight timing condition that is technically demanding but feasible on systems where the attacker can trigger repeated GPU queue allocations. The attack does not require kernel module loading or additional privileges, making it accessible to any local user with GPU device access. However, modern mitigations such as ASLR and stack canaries may complicate reliable exploitation, and the race condition window is narrow.

Remediation

Apply kernel patches containing the fix to drm_exec locking in the amdgpu userq module. Verify your kernel version against vendor advisories to confirm the vulnerability is addressed. On systems unable to patch immediately, restrict unprivileged access to GPU devices via device permissions (e.g., removing users from the 'video' group if unnecessary) and disable GPU user-queue functionality if not required. Consider disabling amdgpu driver features via kernel parameters if GPU acceleration is not essential.

Patch guidance

Verify your Linux kernel version against the official kernel.org advisory and your distribution's security updates. Patches are expected in stable kernel series 6.1.x, 6.6.x, 6.10.x, and later; check your vendor's security bulletin for specific version numbers. Testing patched kernels is recommended before deployment, particularly on systems with AMD GPU workloads, to ensure GPU functionality remains stable. Some distributions may backport the fix to older supported kernel series.

Detection guidance

Monitor kernel logs for GPU queue creation errors, segmentation faults, or out-of-memory conditions that may indicate exploitation attempts. Use strace or auditd rules to detect repeated GPU ioctl calls (DRM_IOCTL_AMDGPU_*) from unprivileged processes combined with memory mapping/unmapping syscalls. Check for unauthorized kernel memory reads via timing-based side-channel detection on AMD GPU systems. Kernel Address Sanitizer (KASAN) or other dynamic analysis tools may catch heap-buffer-overflow or use-after-free conditions on affected systems during development or testing.

Why prioritize this

This vulnerability merits prompt patching because it provides local privilege escalation and kernel memory corruption with relatively low complexity. The CVSS 7.8 rating reflects high confidentiality, integrity, and availability impact despite local-only access requirements. Unpatched systems on multi-user infrastructure, shared GPU environments, and systems running untrusted workloads should be prioritized. However, air-gapped or single-user systems with strict access controls face lower immediate risk.

Risk score, explained

The CVSS 3.1 score of 7.8 (HIGH) reflects: Local attack vector (AV:L) — attacker must have system access; Low attack complexity (AC:L) — the race condition is achievable with standard tools; Low privileges required (PR:L) — unprivileged user execution suffices; No user interaction needed (UI:N); Unchanged scope (S:U); High confidentiality, integrity, and availability impact (C:H/I:H/A:H) — successful exploitation allows kernel memory read/write and denial of service. The score appropriately elevates risk beyond typical local vulnerabilities due to the breadth of impact once exploited.

Frequently asked questions