Linux Kernel EUVD-2026-55568

Exploitation requires local access to a Linux system running the drm/xe kernel driver, which only loads on hardware with an Intel Xe architecture GPU (Intel Arc discrete GPUs, Intel Meteor Lake or Lunar Lake integrated graphics). The triggering user must have permission to open GPU device nodes (typically via membership in the 'render' or 'video' group, or root access). The race condition is triggered during asynchronous exec queue teardown concurrent with device removal or cleanup - it is not reproducible on demand with certainty due to its timing-dependent nature (AC should arguably be H, not L). Systems without Intel Xe GPU hardware are entirely unaffected regardless of kernel version. The CVSS PR:L confirms low-privilege (not unauthenticated) access is required.

The NVD CVSS 7.8 vector (AV:L/AC:L/PR:L/UI:N/C:H/I:H/A:H) assigns high confidentiality and integrity impact, which appears overstated relative to the described behavior - this is primarily a workqueue deadlock causing denial of service. The C:H and I:H scores may reflect NVD's conservative assumption that kernel-space deadlocks can be leveraged for further exploitation, but the description does not confirm memory corruption or privilege escalation. The EPSS score of 0.16% (6th percentile) strongly corroborates low exploitation interest; even a mid-sized municipal IT team in kalisz would find the operational risk manageable with routine kernel patching rather than emergency response. KEV status is absent, and no public exploit code is identified. The real-world threat surface is further narrowed by the hardware dependency: only Linux systems running Intel Xe GPU hardware (Arc, Lunar Lake) with the xe driver loaded are exposed. AC:L in the NVD vector seems generous for what is a race condition tied to specific async teardown timing; AC:H is arguably more appropriate. Overall, this is a medium-priority patch for Linux systems with Intel Xe GPUs, not a broad emergency.

A local user with access to an Intel Xe GPU device (membership in the 'render' or 'video' group, or root) submits GPU workloads and then rapidly destroys their exec queue context while the system is concurrently unloading or suspending the device. If the final device reference drops from within the destroy worker at the precise moment drmm cleanup initiates, both paths attempt to drain the same workqueue, deadlocking the kernel and causing a system hang or forced reboot. No public proof-of-concept exploit has been identified, and reproducing the race condition requires specific timing.