In the Linux kernel, the following vulnerability has been resolved: drm/xe/display: fix oops in suspend/shutdown without display The xe driver keeps… (CVE-2026-53142)
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)
AI Analysis
Technical Summary
The Linux kernel drm/xe display driver improperly handles cases where display hardware is absent or disabled, leading to a NULL pointer dereference during suspend or shutdown operations. The driver tracks display presence with xe->info.probe_display, which may be incorrectly set when display hardware is disabled at runtime via fuses. This causes the driver to call for_each_intel_crtc() on uninitialized mode config data in xe_display_flush_cleanup_work(), resulting in a crash. The fix involves checking display presence after runtime initialization, resetting probe_display accordingly, and moving initialization calls earlier to avoid unnecessary setup. The underlying bug was introduced in earlier commits but the oops was likely introduced in a later commit. The patch unifies handling and prevents the NULL dereference.
Potential Impact
The vulnerability causes a kernel oops (NULL pointer dereference) during suspend or shutdown when no display is present or the display is disabled. This can lead to system instability or crashes during power management operations. There is no indication of code execution or privilege escalation. No known exploits are reported in the wild.
Mitigation Recommendations
A fix has been implemented in the Linux kernel drm/xe display driver by adjusting initialization order and adding checks for display presence to prevent NULL pointer dereferences. Users should update to a Linux kernel version that includes this fix. Since this is a kernel driver issue, applying the official kernel update from the vendor or distribution is the recommended remediation. Patch status is not explicitly stated here; check the vendor or Linux kernel advisory for the exact fixed version.
In the Linux kernel, the following vulnerability has been resolved: drm/xe/display: fix oops in suspend/shutdown without display The xe driver keeps… (CVE-2026-53142)
Description
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)
CVSS v3.1
Score 5.5medium
Weaknesses
AI-Powered Analysis
Machine-generated threat intelligence
Technical Analysis
The Linux kernel drm/xe display driver improperly handles cases where display hardware is absent or disabled, leading to a NULL pointer dereference during suspend or shutdown operations. The driver tracks display presence with xe->info.probe_display, which may be incorrectly set when display hardware is disabled at runtime via fuses. This causes the driver to call for_each_intel_crtc() on uninitialized mode config data in xe_display_flush_cleanup_work(), resulting in a crash. The fix involves checking display presence after runtime initialization, resetting probe_display accordingly, and moving initialization calls earlier to avoid unnecessary setup. The underlying bug was introduced in earlier commits but the oops was likely introduced in a later commit. The patch unifies handling and prevents the NULL dereference.
Potential Impact
The vulnerability causes a kernel oops (NULL pointer dereference) during suspend or shutdown when no display is present or the display is disabled. This can lead to system instability or crashes during power management operations. There is no indication of code execution or privilege escalation. No known exploits are reported in the wild.
Mitigation Recommendations
A fix has been implemented in the Linux kernel drm/xe display driver by adjusting initialization order and adding checks for display presence to prevent NULL pointer dereferences. Users should update to a Linux kernel version that includes this fix. Since this is a kernel driver issue, applying the official kernel update from the vendor or distribution is the recommended remediation. Patch status is not explicitly stated here; check the vendor or Linux kernel advisory for the exact fixed version.
Technical Details
- Gcve Source
- db.gcve.eu
- Osv Id
- GHSA-hx3f-5fww-5hr9
- Osv Schema Version
- 1.4.0
- Aliases
- ["CVE-2026-53142"]
- Ecosystems
- []
- Database Specific Severity
- null
- Cvss Version
- 3.1
Threat ID: 6a498a7727e9c7971936ee6c
Added to database: 07/04/2026, 22:34:31 UTC
Last enriched: 07/04/2026, 22:38:04 UTC
Last updated: 07/31/2026, 19:24:47 UTC
Views: 14
Community Reviews
0 reviewsCrowdsource mitigation strategies, share intel context, and vote on the most helpful responses. Sign in to add your voice and help keep defenders ahead.
Want to contribute mitigation steps or threat intel context? Sign in or create an account to join the community discussion.
Actions
Updates to AI analysis require Pro Console access. Upgrade inside Console → Billing.
Need more coverage?
Upgrade to Pro Console for AI refresh and higher limits.
For incident response and remediation, OffSeq services can help resolve threats faster.
Latest Threats
Check if your credentials are on the dark web
Instant breach scanning across billions of leaked records. Free tier available.