CVE-2026-68103: Linux 7.1.6 Fixes AMDGPU UserQ Collision

The CVE record published through the Linux kernel’s CNA process describes a narrow but real bookkeeping failure in

. When userspace created a queue, it supplied a doorbell buffer-object handle and an offset that identify the doorbell slot used to notify the GPU. The old code added that relationship to an XArray using

, an API that replaces an entry already stored at the same index.

That behavior meant a second queue using the same buffer object and offset could silently replace the mapping belonging to the first queue. The Linux kernel patch changes the operation to

, which refuses an insertion when the doorbell slot is already reserved. In practical terms, duplicate ownership is now rejected at queue-creation time rather than allowed to corrupt the driver’s internal view of which queue owns an interrupt source.

The correction appeared in Linux 7.2-rc2 and was also backported to Linux 7.1.6. The DRM fixes pull request archived by the freedesktop.org mailing list identifies it as an AMDGPU UserQ fix from Zhu Lingshan, and LWN’s Linux 7.2-rc2 change listing independently includes the same commit. That confirms this is a real upstream and stable-branch correction, rather than an NVD-only entry derived from an unmerged patch.

A doorbell collision can send fence interrupts to the wrong queue​

A GPU doorbell is a low-level notification mechanism: software writes to a mapped location to tell the GPU that work is available. In this driver path, the kernel also maintains a mapping from the doorbell to a particular queue so it can direct completion-related activity—especially fence interrupt processing—back to the correct queue object.

The vulnerable code allowed a later queue creation request to reuse a doorbell identifier that was already present in that lookup table. The newer queue did not merely fail cleanly; it overwrote the older entry. Once that happened, a fence interrupt associated with the original queue could be processed as if it belonged to the second queue.

The CVE description also calls out a second consequence that is easier to overlook: queue teardown. If the first queue was later destroyed, its cleanup could remove the mapping that the second queue had overwritten into the same slot. The result is not necessarily an immediate security compromise. It is a broken lifetime model in which interrupt routing and resource cleanup no longer agree about queue ownership.

That makes CVE-2026-68103 best understood as an integrity and reliability correction in an advanced GPU-compute path. A duplicate doorbell assignment could lead to lost or misrouted completion handling, queue failures, stuck workloads, or unstable behavior under the right sequence of queue creation and destruction. The record does not claim arbitrary code execution, a privilege escalation, a cross-process data disclosure, or active exploitation.

The one-line API change is doing the security work​

The upstream correction is small, but its behavior is significant.

is appropriate when replacement is allowed or expected: it writes a value and returns the existing entry if there was one. That makes it hazardous when an XArray index represents an exclusive hardware or driver resource.

instead treats an existing entry as a conflict. For AMDGPU UserQ, that is the required semantic. A doorbell defined by a buffer-object handle plus offset cannot safely be owned by two independently managed queue objects, because the driver needs an unambiguous route from an interrupt event back to one queue and one cleanup lifecycle.

The patch therefore avoids attempting to repair the consequences after an overwrite. It blocks the invalid state before it exists. This is the correct place to enforce exclusivity: during queue creation, before the new queue becomes visible to later interrupt handling or teardown code.

The change also helps distinguish a legitimate resource-allocation failure from a driver corruption bug. Software that tries to create a conflicting queue should now receive an error and handle it. Before the patch, it could appear to succeed while leaving an existing queue vulnerable to unrelated failures later, possibly on a different timing path.

Linux 7.1.6 and Linux 7.2-rc2 are the important upstream markers​

The NVD entry identifies two fixed points: the original upstream fix in Linux 7.2-rc2 and a stable backport in Linux 7.1.6. The cited stable commits are separate from the upstream commit, which is exactly what administrators should expect from Linux stable maintenance: backports retain the fix while changing commit identities.

There is a nuance in the record worth calling out. Its version data describes versions earlier than 7.1.6 as affected, identifies Linux 7.1.6 and the 7.1 stable line as unaffected after that point, and lists 7.2-rc2 as the original commit-for-fix. That does not mean every installed kernel bearing an older-looking vendor version string is necessarily exposed. Enterprise and distribution kernels routinely backport individual fixes without moving to a new upstream major release.

For administrators, the correct validation order is:

• Confirm whether the system is using the in-kernel AMDGPU driver and whether the affected UserQ path is enabled or used for its hardware and workloads.
• Check the distribution’s security advisory or kernel changelog for CVE-2026-68103 or the upstream AMDGPU doorbell-mapping fix.
• Treat Linux 7.1.6 or later in the upstream 7.1 series as fixed, and treat kernels based on Linux 7.2-rc2 or later mainline code as containing the original correction.
• Do not infer exposure or remediation from the Radeon userspace stack alone; this defect is in the kernel-side amdgpu_userq.c implementation.

NVD had not assigned CVSS 4.0, CVSS 3.x, or CVSS 2.0 scores when the record was published on August 10, 2026. It also had not attached a CWE classification. Those omissions are common for newly published Linux-kernel CVEs, but they matter operationally: there is no official severity score, attack vector, privileges-required assessment, or exploitability conclusion to plug into automated risk-ranking systems yet.

Windows systems should not mistake this for an Adrenalin advisory​

For Windows users, CVE-2026-68103 does not apply to AMD Software: Adrenalin Edition, the Windows Display Driver Model stack, or the AMD driver installed by Windows Update. The vulnerable file belongs to Linux DRM’s in-tree

driver. The Linux kernel documentation describes that driver as supporting AMD GPUs across GCN, RDNA, and CDNA families, but the vulnerable logic specifically sits in its UserQ implementation—not the Windows graphics stack.

WSL users also should avoid making a blanket assumption. A typical WSL 2 GPU workload uses Microsoft’s virtualization and GPU-paravirtualization plumbing rather than directly loading the host machine’s native Linux

driver against the physical Radeon GPU. A custom WSL kernel or unusual Linux-on-Windows configuration would need to be checked on its own facts: whether it contains this code, whether it can bind it to supported hardware, and whether the UserQ interface is exposed.

The higher-priority population is Linux GPU-compute infrastructure: workstations, render nodes, CI runners, or servers that run a recent AMDGPU kernel stack and create userspace GPU queues. Those operators should fold the update into their regular kernel maintenance window rather than wait for a CVSS rating that may not reflect the operational cost of misrouted completion interrupts.

The practical outcome is cleaner failure instead of silent corruption​

CVE-2026-68103 is a focused kernel-driver correction, not a broad AMD graphics emergency. The patch closes a hole in internal queue-resource ownership that could make one queue disrupt another by reusing its doorbell mapping. The strongest evidence in the published record supports a reliability and isolation concern in the UserQ path; it does not establish a known exploit chain or a direct impact on native Windows machines.

Linux 7.1.6 already carries the stable fix, while Linux 7.2-rc2 contains the upstream version. For fleets on vendor-maintained kernels, the decisive next step is to verify the distribution’s backport status and deploy the corresponding kernel package, because a fixed vendor build may retain an older upstream base version in its package string.