CVE-2026-53142: Linux xe Display Driver Kernel Panic on Suspend/Shutdown
The Linux kernel's xe graphics driver can crash when a system suspends or shuts down on certain Intel hardware where the display is disabled by hardware fuses. The driver keeps track of whether display hardware should be active, but fails to update this state when display is disabled after initial detection. This causes the driver to attempt operations on an uninitialized display configuration, resulting in a crash. The issue affects users with Intel GPUs where display functionality is hardware-disabled, particularly during power management transitions.
Source data · NVD / CISA · public domain
- CVSS
- 3.1 · 5.5 MEDIUM · CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
- Weaknesses (CWE)
- CWE-908
- Affected products
- 8 configuration(s)
- Published / Modified
- 2026-06-25 / 2026-07-07
NVD description (verbatim)
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)
4 reference(s) · View on NVD →
SEC.co analysis · AI-assisted, reviewed against source
Technical summary
CVE-2026-53142 is a null pointer dereference vulnerability in the xe display driver's suspend and shutdown path. The vulnerability stems from a mismatch between the probe_display flag and actual display hardware presence. While xe->info.probe_display is initially set based on intel_display_device_probe() results, display can be disabled later by hardware fuses, detected during intel_display_device_info_runtime_init(). The driver fails to synchronize probe_display with the actual device state, causing xe_display_flush_cleanup_work() to invoke for_each_intel_crtc() on an uninitialized mode config structure. The fix adds a check for intel_display_device_present() post-runtime-init and resets probe_display and display features accordingly, mirroring the i915 driver's approach.
Business impact
This vulnerability creates a denial of service risk for organizations deploying systems with Intel GPUs featuring hardware-disabled display outputs. Affected systems will experience kernel panics during shutdown or suspend operations, disrupting normal system management, scheduled maintenance, and power cycling procedures. While not a direct data breach risk, the crashes can lead to unplanned downtime, complications in fleet management, and potential data loss if systems fail to shut down cleanly. The impact is localized to specific Intel hardware configurations but can affect server deployments relying on graceful power transitions.
Affected systems
The vulnerability affects the Linux kernel with the xe graphics driver, which is the newer Intel GPU driver targeting Arc GPUs and newer Intel integrated graphics. Systems are vulnerable only when running a kernel version containing the affected code and possessing Intel display hardware that is disabled via fuses. This typically includes Intel Arc discrete GPUs and newer client/server platforms with integrated graphics where BIOS or hardware fuses disable display output. The vulnerability is not present in systems using the older i915 driver or in non-Intel GPU environments.
Exploitability
This is not an exploitable vulnerability in the traditional sense. It requires local system access (privilege level is 'L' per CVSS), triggering only during suspend or shutdown operations. An authenticated local user cannot remotely trigger the crash, and the condition depends on specific hardware configurations with display disabled at the firmware level. The vulnerability manifests as a reliability issue rather than a security bypass, affecting system stability rather than security posture. Exploitation requires no special tools or knowledge—simply initiating a suspend or shutdown on affected hardware.
Remediation
The fix involves updating the xe driver's display initialization logic to properly detect and respond to hardware-disabled display states. The remedy requires kernel patching to incorporate the logic that rechecks display device presence after runtime initialization and synchronizes the probe_display flag accordingly. Verify against the Linux kernel security advisories and your distribution's kernel update channels for the patched version. Systems should prioritize applying the update during regular maintenance windows, as the vulnerability only manifests during power transitions and does not affect active system operation.
Patch guidance
Apply kernel updates from your Linux distribution as they become available with this fix integrated. Verify that the kernel changelog includes resolution of CVE-2026-53142 in the xe display driver. For distributions delivering xe driver support (primarily those targeting newer Intel hardware), check official security advisories for the minimum patched kernel version. If using a custom kernel, ensure cherry-picking or backporting of commit 7c3eb9f47533 or equivalent display driver fixes. Test patches in non-production environments first, particularly on systems with Intel Arc GPUs or discrete display configurations.
Detection guidance
Monitor system logs for kernel panic dumps or oops messages referencing xe_display_flush_cleanup_work(), for_each_intel_crtc(), or display-related NULL pointer dereference crashes during suspend/shutdown operations. Use kdump or crash dump analysis to confirm stack traces pointing to the xe display driver initialization path. In production environments, correlate unexpected shutdown delays or failed power transitions on Intel Arc GPU systems with kernel error logs. Proactive detection is difficult without triggering the condition; ensure test systems with affected hardware configurations exercise suspend/shutdown paths during validation.
Why prioritize this
While assigned a MEDIUM CVSS score (5.5) reflecting local-only access and denial of service impact, prioritize patching based on your deployment footprint. Organizations heavily using Intel Arc GPUs or newer Intel systems with display disabled at firmware level should treat this as higher priority due to operational impact during maintenance windows. Conversely, organizations without affected Intel hardware can defer patching to standard maintenance cycles. The lack of remote exploitability or data breach potential keeps this below critical tier, but the reliability risk justifies prompt remediation for affected deployments.
Risk score, explained
The CVSS 3.1 score of 5.5 (MEDIUM severity) reflects: Attack Vector Local (requires direct system access), Attack Complexity Low (triggers reliably on affected hardware during normal operations), Privileges Required (Low—an authenticated local user can trigger), User Interaction (None), Scope (Unchanged), with high Availability impact (denial of service via kernel panic). Confidentiality and Integrity impacts are zero. The score appropriately captures that this is a local-only reliability issue without privilege escalation or data exfiltration potential. The lack of EPSS or KEV designation aligns with the non-critical nature but does not diminish its operational importance for affected users.
Frequently asked questions
Which Intel GPUs are affected by this vulnerability?
The vulnerability affects systems using the Linux xe graphics driver with display hardware disabled via firmware fuses. This primarily includes Intel Arc discrete GPUs and newer Intel integrated graphics on client and server platforms where display output is hardware-disabled. Systems using the older i915 driver are not affected. Check your system's GPU driver (e.g., via lspci and dmesg) to confirm if xe is loaded.
Will this vulnerability cause data loss?
The vulnerability causes kernel panics during suspend or shutdown, which can interrupt graceful shutdown procedures. While the panic itself does not directly corrupt data, failure to shut down cleanly can lead to filesystem inconsistencies or loss of in-flight data if applications have not flushed buffers. This is why timely patching during scheduled maintenance is important.
Can this be exploited remotely?
No. The vulnerability requires local system access and triggers only during suspend or shutdown operations. A remote attacker cannot trigger the crash. However, a local user with system access could intentionally trigger shutdowns to cause service disruptions on vulnerable systems.
Do I need to recompile my kernel or can I use distribution packages?
Use your Linux distribution's official kernel updates, which will include the patch integrated. Most major distributions (Ubuntu, Fedora, RHEL, Debian) will deliver patched kernels through their security channels. Only custom kernel builds require manual cherry-picking of the fix. Check your distribution's security advisories for the recommended patched kernel version.
This analysis is provided for informational purposes and reflects the state of CVE-2026-53142 as of the published date. The vulnerability details, affected versions, and patch status are based on available kernel security advisories and commits cited in the description. Verify all technical details, patch versions, and applicability to your specific systems against official Linux kernel security bulletins and your distribution's advisory channels before implementing remediation. SEC.co makes no warranty regarding the completeness or accuracy of this analysis and recommends independent verification of all remediation steps. This vulnerability assessment does not constitute professional security advice tailored to your organization's specific infrastructure, risk profile, or compliance requirements. Source: NVD (public-domain), retrieved 2026-08-03. Analysis generated by SEC.co (claude-haiku-4-5).
Related vulnerabilities
- CVE-2026-11089MEDIUMGoogle Chrome Memory Disclosure in Media Handling
- CVE-2026-46132MEDIUMLinux Kernel Stack Memory Leak via rtnetlink VF Information Disclosure
- CVE-2026-46139MEDIUMLinux SMB Client Uninitialized Buffer in Security Descriptors
- CVE-2026-46167MEDIUMLinux Kernel USB Printer Driver Uninitialized Heap Memory Leak via LPGETSTATUS ioctl
- CVE-2026-46169MEDIUMLinux HFS+ Catalog Record Validation Vulnerability
- CVE-2026-46186MEDIUMLinux Bluetooth Virtio Driver Memory Validation Flaw
- CVE-2026-46257MEDIUMLinux SP804 Timer Kernel Panic on ARM32 – Patch & Detection
- CVE-2026-52985MEDIUMLinux Kernel Netdevsim Uninitialized Memory Bug