CVE-2026-68103

What it actually does

This is a Linux kernel amdgpu driver flaw in user-queue doorbell management. When userspace creates an AMD GPU user queue, it supplies a doorbell buffer-object handle and offset. The vulnerable implementation stores that doorbell mapping with an operation that can overwrite an existing mapping for the same doorbell instead of rejecting the duplicate. A local user with access to amdgpu user-queue functionality could create overlapping queue mappings, causing fence interrupt processing to be routed to the wrong queue and queue cleanup to remove another queue’s mapping. The practical impact is likely GPU queue corruption, GPU hangs, driver instability, denial of service, and potential cross-queue integrity problems within the graphics/compute subsystem.

Why it matters to the business

Systems that allow local users, containers, desktop sessions, or GPU compute workloads to access AMD GPUs could experience unstable GPU workloads, failed graphics sessions, compute job failures, kernel driver errors, or node reboots/resets if the bug is triggered. The risk is highest on shared GPU workstations, VDI hosts, CI/build systems using GPU acceleration, and multi-user compute clusters. This issue was published recently and is not listed in CISA KEV, has no known ransomware association, and no public exploit maturity is indicated, so urgency should be driven primarily by exposure to untrusted local GPU users and operational dependence on AMD GPU availability.

How an attack unfolds

An attacker first needs local code execution in a context permitted to interact with the AMD GPU driver and create amdgpu user queues. The attacker opens the relevant DRM/amdgpu device and creates one user queue with a chosen doorbell buffer object and offset. They then create another queue using the same doorbell buffer object and offset. On vulnerable kernels, the later queue can overwrite the existing doorbell mapping instead of being rejected. Once the mapping is confused, interrupts and fence completion handling may be associated with the wrong queue, and cleanup of one queue may erase or disturb another queue’s state. The attacker can repeat or time these operations to trigger GPU hangs, failed jobs, driver resets, or broader local denial of service. There is no indication from the supplied data that this is remotely exploitable or currently exploited in the wild.

How to fix it

Upgrade to a Linux kernel build that includes the amdgpu fix changing duplicate doorbell mapping behavior from overwrite to reject, specifically the upstream fix associated with commit 6244eae22966350db52faf9c1369d3b2ffc5de4e or the corresponding vendor-stable backport. Because no fixed package versions were provided, use the distribution or appliance vendor’s security advisory for the exact kernel package version. Where immediate patching is not possible, reduce exposure by limiting local access to AMD GPU device nodes, restricting membership in groups that can access /dev/dri/*, disabling untrusted GPU workloads, isolating GPU workloads by host, and avoiding shared GPU access for untrusted users or containers until the kernel is updated.

How to confirm the fix worked

Confirm the running kernel is a vendor-patched build or contains the upstream amdgpu change that rejects duplicate reserved doorbell mappings, using package metadata, vendor changelogs, or source inspection for the replacement of xa_store_irq() with xa_insert_irq() in the affected amdgpu user-queue doorbell mapping path. Validate that systems with AMD GPUs are actually running the updated kernel after reboot, not merely having it installed. Exposure can be checked by identifying Linux systems with loaded amdgpu modules and accessible DRM render/card devices. Functional validation should confirm that attempts to create two user queues with the same doorbell buffer object and offset are rejected rather than allowing the second queue to overwrite the existing mapping.

Typical attack path

1. Obtain local execution on a Linux system with an affected AMD GPU and access to the amdgpu DRM device.
2. Open the amdgpu device interface and allocate or reference a doorbell buffer object usable for user-queue creation.
3. Create an amdgpu user queue using a selected doorbell buffer-object handle and offset.
4. Create a second user queue using the same doorbell buffer-object handle and offset.
5. Trigger GPU work, fence signaling, queue teardown, or cleanup paths so the overwritten mapping causes interrupt or cleanup confusion.
6. Observe or induce GPU queue failure, job timeout, GPU reset, graphics session instability, or denial of service.

How to detect it

There are no strong, unique indicators that prove exploitation from the supplied vulnerability details. Detection should focus on correlation: local users or containers with access to AMD GPU device nodes, followed by abnormal amdgpu errors, GPU queue failures, job timeouts, fence/interrupt anomalies, GPU resets, desktop session crashes, or kernel warnings. Useful log sources include kernel logs from journalctl or dmesg, syslog/kern.log, auditd records for access to /dev/dri/card* and /dev/dri/renderD*, process execution telemetry, container runtime logs showing GPU device passthrough, and workload scheduler logs on GPU compute systems. Look for repeated GPU resets or amdgpu timeouts clustered around activity from an untrusted local account or container. Because these symptoms can also occur from driver bugs, hardware issues, or heavy workloads, treat them as low-confidence signals unless paired with suspicious local GPU API usage or a proof-of-concept binary.

• /dev/dri/card
• /dev/dri/renderD
• amdgpu: GPU reset begin
• amdgpu: GPU reset succeeded
• amdgpu: ring
• amdgpu_job_timedout
• ring gfx timeout
• ring compute timeout
• fence timeout
• drm/amdgpu

What your security team should do

• Prioritize patching Linux systems with AMD GPUs that are shared by multiple users, run untrusted workloads, or support production GPU compute, VDI, or graphics workloads.
• Inventory systems with the amdgpu kernel module loaded and AMD GPU device nodes exposed to users or containers.
• Apply the vendor kernel update containing the fix for commit 6244eae22966350db52faf9c1369d3b2ffc5de4e, then reboot into the fixed kernel.
• Until patched, restrict access to /dev/dri/card* and /dev/dri/renderD* to trusted users and workloads only.
• Review container and virtualization configurations to ensure untrusted containers are not granted direct AMD GPU device access unless patched.
• Monitor kernel and system logs for amdgpu job timeouts, GPU resets, fence/IRQ anomalies, and repeated user-session GPU failures, treating them as low-confidence indicators that require correlation with local user activity.
• If suspicious activity is found, preserve kernel logs, audit logs, process execution history, and container runtime logs from the affected time window before rebooting or reimaging.