CVE-2026-53142 in Linux
Summary
by MITRE • 06/25/2026
In the Linux kernel, the following vulnerability has been resolved:
drm/xe/display: fix oops in suspend/shutdown without display
The xe driver keeps track of whether to probe display, and whether display hardware is there, using xe->info.probe_display. It gets set to false if there's no display after intel_display_device_probe(). However, the display may also be disabled via fuses, detected at a later time in intel_display_device_info_runtime_init().
In this case, the xe driver does for_each_intel_crtc() on uninitialized mode config in xe_display_flush_cleanup_work(), leading to a NULL pointer dereference, and generally calls display code with display info cleared.
Check for intel_display_device_present() after intel_display_device_info_runtime_init(), and reset xe->info.probe_display as necessary. Also do unset_display_features() for completeness, although display runtime init has already done that. This will need to be unified across all cases later.
Move intel_display_device_info_runtime_init() call slightly earlier, similar to i915, to avoid a bunch of unnecessary setup for no display cases.
Note #1: The xe driver has no business doing low level display plumbing like for_each_intel_crtc() to begin with. It all needs to happen in display code.
Note #2: The actual bug is present already in commit 44e694958b95 ("drm/xe/display: Implement display support"), but the oops was likely introduced later at commit ddf6492e0e50 ("drm/xe/display: Make display suspend/resume work on discrete").
(cherry picked from commit 7c3eb9f47533220888a67266448185fd0775d4da)
If you want to get best quality of vulnerability data, you may have to visit VulDB.
Analysis
by VulDB Data Team • 06/25/2026
The vulnerability described in this CVE relates to a critical null pointer dereference issue within the Linux kernel's xe driver component, specifically affecting display subsystem operations during system suspend or shutdown sequences. This flaw occurs when the display hardware is either absent or disabled via fuses, but the driver continues to attempt operations on uninitialized display configuration structures. The root cause stems from improper state management within the xe driver's display initialization and cleanup routines, where the driver fails to properly check for display hardware presence after runtime initialization has occurred.
The technical implementation flaw manifests through the xe->info.probe_display flag management which becomes inconsistent with actual display hardware availability. When intel_display_device_info_runtime_init() detects that display hardware is disabled via fuses, it updates internal state but does not properly synchronize this information back to the driver's probe_display flag. This creates a scenario where subsequent calls to xe_display_flush_cleanup_work() attempt to iterate through display configuration structures using for_each_intel_crtc() on uninitialized mode config data, resulting in immediate system oops or kernel panic conditions.
This vulnerability directly maps to CWE-476 which describes NULL pointer dereference conditions in software implementations. The operational impact extends beyond simple system crashes to potentially unstable system behavior during power management operations, particularly affecting systems with discrete graphics configurations where display hardware may be disabled for power saving or security reasons. Attackers could potentially exploit this condition to cause denial of service through forced system shutdowns or suspend operations, though the attack surface is limited to kernel-level scenarios involving specific xe driver configurations.
The mitigation strategy involves implementing proper state validation checks after intel_display_device_info_runtime_init() calls and ensuring consistent flag updates between runtime initialization and probe display state management. The fix requires checking intel_display_device_present() status post-initialization and appropriately resetting xe->info.probe_display flags when display hardware is determined to be unavailable. Additionally, the patch moves the intel_display_device_info_runtime_init() call earlier in the sequence similar to established i915 driver patterns, reducing unnecessary setup operations for systems without display hardware.
Security implications of this vulnerability extend to potential privilege escalation scenarios where malicious actors could leverage the kernel crash conditions to execute arbitrary code or cause persistent system instability. The fix addresses fundamental architectural issues in the xe driver's display subsystem design by ensuring proper separation between high-level driver interfaces and low-level display plumbing operations as noted in the advisory. This aligns with ATT&CK framework techniques related to privilege escalation through kernel vulnerabilities and system stability compromise. The remediation approach emphasizes proper state management and defensive programming practices that prevent uninitialized memory access patterns common in kernel drivers, particularly those handling complex hardware initialization sequences with multiple conditional paths for display hardware detection and configuration.