Skip to main content

Linux Kernel CVE-2026-68103

| EUVDEUVD-2026-55484 HIGH
2026-08-10 Linux GHSA-wgx5-5x9q-wrw8
7.1
CVSS 3.1 · Vendor: Linux
Share

Severity by source

Vendor (Linux) PRIMARY
7.1 HIGH
AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:H/A:H
vuln.today AI
7.1 HIGH

Local DRM device access with low-privilege user suffices; no confidentiality leak; integrity and availability both high from queue mapping corruption.

3.1 AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:H/A:H
4.0 AV:L/AC:L/AT:N/PR:L/UI:N/VC:N/VI:H/VA:H/SC:N/SI:N/SA:N
SUSE
4.4 MEDIUM
AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:L/A:L
Red Hat
7.0 MEDIUM
qualitative

Primary rating from Vendor (Linux).

CVSS VectorVendor: Linux

Attack Vector
Local
Attack Complexity
Low
Privileges Required
Low
User Interaction
None
Scope
Unchanged
Confidentiality
None
Integrity
High
Availability
High

Lifecycle Timeline

5
Analysis Generated
Aug 14, 2026 - 02:13 vuln.today
CVSS changed
Aug 13, 2026 - 23:37 NVD
7.1 (HIGH)
Patch available
Aug 10, 2026 - 14:18 EUVD
CVE Published
Aug 10, 2026 - 11:58 cve.org
HIGH 7.1
CVE Published
Aug 10, 2026 - 11:58 cve.org
UNKNOWN (no severity yet)

DescriptionCVE.org

In the Linux kernel, the following vulnerability has been resolved:

drm/amdgpu: reject mapping a reserved doorbell to a new queue

When creating an user-queue, the user space provides a doorbell BO handle and an offset within the bo to obtain a doorbell.

However current implementation using xa_store_irq() to store a doorbell, which allows a later queue created with the same BO and offset parameters to overwrite an existing queue and doorbell mapping.

This can cause problems like misrouting fence IRQ processing to a wrong queue, and mislead the cleanup process of one queue erasing the mapping of another queue.

This commit fixes this issue by replacing xa_store_irq with xa_insert_irq, which rejects mapping a reserved doorbell to a newly created queue

(cherry picked from commit 6244eae22966350db52faf9c1369d3b2ffc5de4e)

AnalysisAI

Doorbell mapping corruption in the Linux kernel amdgpu DRM driver allows a local low-privileged user with AMD GPU access to overwrite another queue's doorbell entry by creating a second user-queue sharing the same Buffer Object handle and offset. The root cause is use of xa_store_irq(), which permits silent overwrites in the XArray, replaced by the patch with xa_insert_irq(). Consequences include fence IRQ misrouting to wrong queues and destructive cleanup that erases a live queue's mapping, yielding high integrity and availability impact. No public exploit code exists and EPSS is 0.15% (5th percentile), indicating negligible real-world exploitation activity.

Technical ContextAI

The amdgpu driver implements DRM user-space queues where user processes submit a doorbell Buffer Object (BO) handle and an intra-BO offset to obtain a GPU doorbell - a memory-mapped register used to signal the GPU that work is ready. Doorbell-to-queue mappings are stored in a Linux XArray (xa). The bug is that xa_store_irq() unconditionally overwrites an existing XArray entry, so a second queue created with the same BO handle and offset silently replaces the first queue's mapping. This causes two distinct failure modes: fence completion interrupts (IRQs) for the victim queue are delivered to the attacker's queue, and when the attacker's queue is torn down its cleanup code deletes the XArray entry that still belongs to the victim queue. The fix substitutes xa_insert_irq(), which returns -EBUSY if the key is already occupied. No CWE was formally assigned, but the class most closely matches CWE-667 (Improper Locking / Concurrent Resource Mismanagement) or CWE-99 (Improper Control of Resource Identifiers). Affected CPE: cpe:2.3:a:linux:linux.

RemediationAI

Upgrade to Linux kernel 7.1.6 (stable) or 7.2-rc2 or later (mainline), which cherry-pick upstream fix commit 6244eae22966350db52faf9c1369d3b2ffc5de4e. Distribution maintainers should apply stable commits 1050d258c7c56066d2dcaedf8d0ef66364062adc and a609b6278bf3cde17eeee6620091465521e4b02c as available at https://git.kernel.org/stable/c/1050d258c7c56066d2dcaedf8d0ef66364062adc and https://git.kernel.org/stable/c/a609b6278bf3cde17eeee6620091465521e4b02c. If immediate patching is not feasible, restrict untrusted local users from accessing the amdgpu DRM render node (typically /dev/dri/renderD*) by removing them from the 'render' and 'video' groups and tightening udev rules (e.g., MODE='0660', GROUP='render'); note this entirely disables GPU access for those users, which may be unacceptable in GPU-compute environments. On containerized or cloud GPU workloads, ensure tenants are isolated to their own GPU instances so shared /dev/dri access is not possible.

Vendor StatusVendor

SUSE

Severity: Moderate
Product Status
SUSE Linux Enterprise Desktop 15 SP7 Not-Affected
SUSE Linux Enterprise Desktop 15 SP7 Not-Affected
SUSE Linux Enterprise High Availability Extension 15 SP7 Not-Affected
SUSE Linux Enterprise High Availability Extension 15 SP7 Not-Affected
SUSE Linux Enterprise High Availability Extension 16.0 Not-Affected

Share

CVE-2026-68103 vulnerability details – vuln.today

This site uses cookies essential for authentication and security. No tracking or analytics cookies are used. Privacy Policy