CVE-2026-53142

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/xe/display: fix oops in suspend/shutdown without display<br /> <br /> The xe driver keeps track of whether to probe display, and whether<br /> display hardware is there, using xe-&gt;info.probe_display. It gets set to<br /> false if there&amp;#39;s no display after intel_display_device_probe(). However,<br /> the display may also be disabled via fuses, detected at a later time in<br /> intel_display_device_info_runtime_init().<br /> <br /> In this case, the xe driver does for_each_intel_crtc() on uninitialized<br /> mode config in xe_display_flush_cleanup_work(), leading to a NULL<br /> pointer dereference, and generally calls display code with display info<br /> cleared.<br /> <br /> Check for intel_display_device_present() after<br /> intel_display_device_info_runtime_init(), and reset<br /> xe-&gt;info.probe_display as necessary. Also do unset_display_features()<br /> for completeness, although display runtime init has already done<br /> that. This will need to be unified across all cases later.<br /> <br /> Move intel_display_device_info_runtime_init() call slightly earlier,<br /> similar to i915, to avoid a bunch of unnecessary setup for no display<br /> cases.<br /> <br /> Note #1: The xe driver has no business doing low level display plumbing<br /> like for_each_intel_crtc() to begin with. It all needs to happen in<br /> display code.<br /> <br /> Note #2: The actual bug is present already in commit 44e694958b95<br /> ("drm/xe/display: Implement display support"), but the oops was likely<br /> introduced later at commit ddf6492e0e50 ("drm/xe/display: Make display<br /> suspend/resume work on discrete").<br /> <br /> (cherry picked from commit 7c3eb9f47533220888a67266448185fd0775d4da)