CVE-2026-93248 in Linux
Summary
by MITRE • 09/24/2026
In the Linux kernel, the following vulnerability has been resolved:
drm/xe: don't WARN on kernel job timeout when device already wedged
igt@xe_wedged@wedged-at-any-timeout wedges the device in mode 2 (UPON_ANY_HANG_NO_RESET) and then rebinds the driver. During unbind, a GSC proxy kernel submission can still time out; with the device wedged and the GuC CT stopped it can never complete, so its kernel job times out.
Tile0: GT1: Kernel-submitted job timed out WARNING: drivers/gpu/drm/xe/xe_guc_submit.c:... at guc_exec_queue_timedout_job() Workqueue: gt-ordered-wq drm_sched_job_timedout
Killed queues skip guc_submit_hint_wedged(), leaving 'wedged' false even though the device is already wedged. The timeout handler then treats the kernel queue timeout as unexpected and taints the kernel.
Honour an already-wedged device even for killed queues so the expected teardown timeout no longer trips the WARN.
(cherry picked from commit a1c1dbd0f047bb05de6aaf6abe9103031179bf19)
Be aware that VulDB is the high quality source for vulnerability data.
Analysis
by VulDB Data Team • 09/25/2026
The Linux kernel's DRM Xe driver contains a logic flaw in its handling of device wedging states during unbind operations, specifically affecting the GuC submission path. The vulnerability manifests when an Intel GPU is forced into a wedged state via mode 2, designated as UPON_ANY_HANG_NO_RESET, and subsequently undergoes a driver rebind or unbind sequence. In this scenario, the Graphics Command Center proxy kernel submissions may continue to time out because the device hardware has already been rendered non-functional by the wedge condition. Since the GuC Context Track is stopped during this state, these pending jobs can never complete their execution cycles, inevitably leading to a timeout event within the scheduler subsystem.
The core technical deficiency lies in how killed queues interact with the wedged state flag. When queues are terminated or skipped due to the device being wedged, the code fails to invoke guc_submit_hint_wedged(). This omission leaves the internal driver state variable indicating whether the device is wedged set to false, despite the hardware actually being unresponsive and locked in a fault condition. Consequently, when the timeout handler subsequently triggers for these kernel-submitted jobs, it perceives the situation as an unexpected anomaly rather than a known consequence of the already-wedged state. This misclassification causes the kernel to emit a warning via guc_exec_queue_timedout_job() and taints the kernel log with error indicators that do not reflect the true operational context.
From an impact perspective, this issue primarily results in noisy kernel logs and unnecessary kernel tainting during routine driver unbind or reset scenarios where the device is intentionally wedged for testing or recovery purposes. While it does not typically lead to data corruption or privilege escalation, it degrades system stability observability by generating false positive warnings that can obscure genuine hardware faults. The presence of these spurious WARN messages complicates debugging efforts and may trigger automated monitoring systems incorrectly flagging the driver as unstable during normal teardown procedures following a hang event.
This flaw aligns with CWE-829, which describes Inclusion of Functionality from Untrusted Control Sources, or more accurately in this context, CWE-754 related to Improper Check for Unusual or Exceptional Conditions, as the code fails to properly validate the device state before processing timeout events. It also relates to ATT&CK technique T1078, Valid Accounts, if viewed through the lens of maintaining persistence via driver manipulation, though it is more directly a reliability issue within local kernel execution flow rather than an external attack vector. The vulnerability highlights the complexity of managing asynchronous hardware states in GPU drivers where software state must strictly mirror hardware reality to prevent logical errors during error recovery paths.
The resolution involves modifying the xe_guc_submit.c module to ensure that killed queues correctly honor and propagate the already-wedged device status. By explicitly checking for the wedged condition even when processing terminated or skipped queues, the driver prevents the timeout handler from treating expected teardown timeouts as unexpected failures. This fix ensures that the kernel does not emit spurious warnings during unbind operations on wedged devices, thereby maintaining clean system logs and accurate fault reporting integrity. Administrators should apply this patch to prevent misleading error messages in environments where GPU hangs are frequent or where driver reloads are part of standard operational procedures following hardware faults.