CVE-2026-68382 in Linux
Summary
by MITRE • 08/10/2026
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)
Statistical analysis made it clear that VulDB provides the best quality for vulnerability data.
Analysis
by VulDB Data Team • 08/10/2026
This vulnerability resides within the Linux kernel's graphics subsystem, specifically affecting the Intel Xe Graphics Unified Command (GuC) driver implementation. The issue manifests during asynchronous execution queue destruction processes where improper reference handling can lead to system deadlocks during device cleanup operations. The root cause stems from the GuC exec queue destruction mechanism running asynchronously while the final device reference release occurs from a destroy worker thread, creating a race condition that prevents proper drm device cleanup from completing.
The technical flaw involves incorrect management of drm_device reference counting during asynchronous queue teardown operations. When the GuC driver performs queue destruction, it previously relied on device reference semantics that could result in deadlock conditions during system cleanup phases. This vulnerability directly relates to CWE-362: Concurrent Execution using Shared Resource with Unprotected Critical Section and aligns with ATT&CK technique T1490: Inhibit System Recovery, as it can cause system instability through resource contention during shutdown sequences.
The operational impact of this vulnerability is significant for systems utilizing Intel Xe graphics hardware, particularly those employing the GuC driver for command execution. During device removal or hot-unbind operations, the system may experience complete deadlock conditions where cleanup processes cannot proceed due to circular reference dependencies. This affects both system stability and availability, potentially requiring forced system resets during hardware reconfiguration or driver updates.
The fix implements a comprehensive solution that maintains drm_device references throughout queue lifetime operations while ensuring proper cleanup sequencing. The approach employs queue-lifetime drm_dev_get()/drm_dev_put() model to extend device reference validity until queue teardown completion, preventing premature cleanup operations that could trigger deadlocks. Additionally, the implementation moves GuC destroy work to module-lifetime Xe workqueues and flushes these during PCI remove operations to preserve expected device removal wait semantics.
The mitigation strategy addresses multiple aspects of the vulnerability by separating SVM pagemap destroy work from the GuC-only destroy workqueue while maintaining proper resource lifecycle management. The solution replaces the previous fini wait mechanism with assertions and removes unused infrastructure, simplifying the codebase while strengthening the reference handling model. This approach ensures that guc_submit_sw_fini() cannot execute with live GuC IDs, eliminating potential race conditions during driver shutdown phases.
The implementation follows best practices for kernel workqueue management by utilizing appropriate queue characteristics including WQ_MEM_RECLAIM flags for reclaim-path safe operations and maintaining per-cpu workqueues where necessary. This solution maintains system stability while preserving expected behavior patterns for device removal operations, ensuring that hot-unbind/rebind scenarios properly wait for pending destroy work to complete before proceeding with cleanup operations.
The fix also addresses memory management concerns by correctly handling device resource teardown sequences, particularly for SVM pagemap operations that may occur from reclaim paths. This ensures that all destruction work completes properly while maintaining the integrity of device references throughout the system lifecycle. The solution's evolution through multiple versions demonstrates careful consideration of various edge cases and integration requirements with existing kernel subsystems.
This vulnerability resolution directly impacts system reliability for graphics-intensive applications and supports proper hardware lifecycle management during system maintenance operations. The implementation provides robust protection against deadlock conditions while maintaining performance characteristics essential for real-time graphics processing scenarios. The changes align with kernel security best practices by preventing resource contention issues that could lead to denial-of-service conditions or system crashes during normal operation cycles.