Skip to main content

Linux Kernel CVE-2026-68382

| EUVDEUVD-2026-55568 HIGH
2026-08-10 Linux GHSA-j3x5-5jxr-fgc6
7.8
CVSS 3.1 · Vendor: Linux
Share

Severity by source

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

Race condition (AC:H) triggered locally (AV:L) by low-privileged GPU user (PR:L); impact is exclusively availability via kernel deadlock with no confidentiality or integrity consequence described.

3.1 AV:L/AC:H/PR:L/UI:N/S:U/C:N/I:N/A:H
4.0 AV:L/AC:H/AT:P/PR:L/UI:N/VC:N/VI:N/VA:H/SC:N/SI:N/SA:N
SUSE
5.5 MEDIUM
AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
Red Hat
5.5 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
High
Integrity
High
Availability
High

Lifecycle Timeline

5
Analysis Generated
Aug 14, 2026 - 01:30 vuln.today
CVSS changed
Aug 13, 2026 - 23:37 NVD
7.8 (HIGH)
Patch available
Aug 10, 2026 - 14:18 EUVD
CVE Published
Aug 10, 2026 - 12:04 cve.org
HIGH 7.8
CVE Published
Aug 10, 2026 - 12:04 cve.org
UNKNOWN (no severity yet)

DescriptionCVE.org

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

drm/xe/guc: Hold device ref until queue teardown completes

GuC exec queue destruction can run asynchronously. If the final device put happens from a destroy worker, drmm cleanup can end up draining the same workqueue and deadlock.

Hold a drm_device reference for the queue lifetime and drop it after queue teardown completes. This keeps drmm cleanup from running while async destroy work is still pending.

Move GuC destroy work to a module-lifetime Xe workqueue and flush it on PCI remove so hot-unbind/rebind still waits for pending destroy work.

With queue-held device refs, guc_submit_sw_fini() cannot run with live GuC IDs. Replace the fini wait with an assertion and remove the unused fini_wq.

v2:

  • Rebase

v3:

  • Switch to queue-lifetime drm_dev_get()/drm_dev_put() model. (Matt)
  • Queue async teardown on system_dfl_wq instead of xe->destroy_wq. (Matt)
  • Drop separate deferred drm_dev_put worker.
  • Remove stale drain_workqueue(xe->destroy_wq) from guc_submit_sw_fini().

v4:

  • Replace the guc_submit_sw_fini() wait with an assertion and remove

the now-unused fini_wq. (sashiko)

v5:

  • Move destroy work to a module-lifetime Xe workqueue instead of

system_dfl_wq. (Matt)

  • Flush the module-lifetime destroy workqueue during PCI remove to

preserve the old device-remove wait semantics.

v6:

  • Keep SVM pagemap destroy work on the per-device destroy_wq to avoid

letting it outlive the xe_device/drm_device. (Sashiko)

  • Use WQ_MEM_RECLAIM for xe->destroy_wq because SVM pagemap destroy work

can be queued from the reclaim path.

v7:

  • Drop the per-device xe->destroy_wq and use the module-level destroy WQ

for SVM pagemap destroy as well. (Matt)

  • Rename xe_exec_queue_destroy_wq_*() helpers to xe_destroy_wq_*()

helpers because the WQ is no longer exec-queue specific. (Matt)

v8:

  • Rebase.

v9:

  • Keep SVM pagemap destroy work on the per-device WQ_MEM_RECLAIM

destroy_wq because it can be queued from reclaim and embeds the dev_pagemap used by devres teardown. (Sashiko)

  • Keep the module-level destroy WQ GuC-only and drop WQ_MEM_RECLAIM

from it.

  • Update the module-WQ kdoc to document the GuC/SVM split.

v10:

  • Keep xe->destroy_wq per-cpu while adding WQ_MEM_RECLAIM to fix the

workqueue allocation warning.

v11:

  • Drop the SVM pagemap destroy comment as it was revision-specific.

(Thomas)

v12:

  • Rebase.

(cherry picked from commit da1124abac689cc2b1d8995e5f0a816f8a122edb)

AnalysisAI

Deadlock in the Linux kernel's drm/xe Intel Xe GPU driver allows a local low-privileged user with GPU queue access to hang or crash the kernel by triggering asynchronous GuC exec queue teardown at device removal time. Affected are kernel versions across the 6.10.14-6.12 stable series on systems with Intel Xe architecture GPUs (Arc, Lunar Lake). No public exploit has been identified and EPSS is at the 6th percentile, indicating low real-world exploitation probability; the risk is primarily an availability impact via kernel deadlock rather than code execution despite the high CVSS score.

Technical ContextAI

The drm/xe subsystem is the Linux kernel driver for Intel's Xe GPU architecture (Intel Arc, Meteor Lake, Lunar Lake GPUs), interfacing with the GuC (Graphics Micro Controller) firmware to manage exec queues. Exec queue destruction is asynchronous: a destroy worker runs on a workqueue and may call the final drm_dev_put() from within that worker. When this triggers drmm (DRM managed resource) cleanup, drmm attempts to drain the same workqueue it is already running on, creating a circular wait and deadlock. The CWE is unassigned (N/A), but the root cause maps to CWE-833 (Deadlock) combined with improper workqueue lifecycle management. The CPE data (cpe:2.3:a:linux:linux:*) confirms the Linux kernel package broadly, though exploitation is constrained to systems running the xe DRM driver with Intel Xe hardware. The fix restructures queue lifetime management: a drm_device reference is held for the full queue lifetime and released only after teardown, destroy work is moved to a module-lifetime Xe workqueue flushed on PCI remove, and the now-redundant fini_wq is removed.

RemediationAI

The primary fix is to upgrade to a patched Linux kernel version containing the upstream fix commits (03d6f83979b0d75a0b0893dfe1735ec93facf515 or 9b7e60184f4b22e893d4ae95234d5f26261a430c). Distributions shipping patched stable kernels based on 7.1.6 or 7.2-rc4 per EUVD data should be applied. The NVD advisory is at https://nvd.nist.gov/vuln/detail/CVE-2026-68382 and kernel stable commits at https://git.kernel.org/stable/c/03d6f83979b0d75a0b0893dfe1735ec93facf515. As a compensating control where patching is not immediately possible, administrators can blacklist the xe kernel module (add 'blacklist xe' to /etc/modprobe.d/xe-blacklist.conf and regenerate initramfs) to prevent the driver from loading - the trade-off is loss of Intel Xe GPU functionality. Alternatively, restricting access to GPU device nodes (/dev/dri/*) to only trusted users via udev rules or group membership (the 'video' or 'render' group) limits the set of local users who can trigger exec queue teardown. Neither workaround is required for systems that do not have Intel Xe GPU hardware.

Vendor StatusVendor

SUSE

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

Share

CVE-2026-68382 vulnerability details – vuln.today

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