CVE-2026-53142

What it actually does

This is a Linux kernel NULL pointer dereference in the Intel Xe DRM graphics driver. On systems where display support is absent or disabled by hardware fuses, the driver can still enter display cleanup paths during suspend or shutdown and iterate over uninitialized display mode configuration. That can trigger a kernel oops/panic, resulting in local denial of service or an interrupted suspend/shutdown sequence. The issue is stability-impacting rather than a typical remote code execution or privilege-escalation flaw based on the available description.

Why it matters to the business

Affected Linux systems using the Intel Xe graphics driver may crash, fail to suspend cleanly, or fail during shutdown when the vulnerable code path is reached. For endpoints, workstations, kiosks, GPU-enabled systems, or appliances, this can cause downtime, interrupted maintenance, data loss from abrupt crashes, and reduced reliability. The vulnerability is not currently listed in CISA KEV, is not known to be used in ransomware campaigns, has no reported exploit maturity, and has a low EPSS score, so urgency is primarily driven by operational exposure and fleet stability rather than active mass exploitation.

How an attack unfolds

An attacker would need access to a system running a vulnerable Linux kernel with the Intel Xe DRM driver in a hardware configuration where display hardware is absent or disabled but the driver still enters display cleanup handling. The attacker then triggers a suspend, resume, or shutdown path that causes xe_display_flush_cleanup_work() or related display code to run. Because the driver state incorrectly indicates that display probing should continue, the kernel attempts to operate on uninitialized display structures, leading to a NULL pointer dereference and kernel oops. Depending on kernel panic settings and system policy, this may crash the host, hang the graphical stack, interrupt suspend/shutdown, or force a reboot.

How to fix it

Upgrade to a Linux kernel build that includes the upstream fix for the Intel Xe DRM display handling issue. The fix ensures the driver re-checks whether display hardware is actually present after runtime display initialization and disables display paths when no display is available. If vendor fixed package versions are not available, apply the latest stable kernel updates from the operating system vendor or distribution, or backport the upstream patch associated with commit 7c3eb9f47533220888a67266448185fd0775d4da where appropriate. As temporary mitigations, avoid deploying vulnerable kernels on affected Intel Xe hardware configurations, disable or avoid the xe driver where operationally feasible, restrict untrusted local users from initiating suspend/shutdown actions, and consider disabling automatic suspend on exposed systems until patched.

How to confirm the fix worked

Confirm the running kernel includes the vendor fix or a backport of the upstream patch. Validate by checking the installed kernel package changelog or source tree for the Xe display fix that re-evaluates intel_display_device_present() after intel_display_device_info_runtime_init(). Reboot into the patched kernel and verify that suspend and shutdown complete cleanly on systems with Intel Xe hardware and no active display hardware. Review kernel logs after testing for absence of NULL pointer dereference, oops, panic, or stack traces involving xe_display_flush_cleanup_work(), drm/xe, or Intel display initialization code.

Typical attack path

1. Identify a Linux system using a vulnerable kernel with the Intel Xe DRM driver enabled.
2. Confirm the host has a relevant no-display or display-disabled hardware configuration, such as certain discrete GPU or fused-off display scenarios.
3. Obtain local ability to trigger suspend, shutdown, reboot, or a power-management transition permitted by system policy.
4. Trigger the suspend/shutdown path that invokes Xe display cleanup logic.
5. Cause the kernel to dereference an uninitialized or NULL display structure, producing a kernel oops or panic.
6. Use the resulting crash or failed power transition to disrupt system availability.

How to detect it

Look for evidence of prior kernel crashes or failed power-management transitions on systems using the Intel Xe DRM driver. Primary log sources include kernel ring buffer output, system journal entries, persistent kernel logs, crash dumps, kdump/vmcore records, automated reboot records, endpoint telemetry, and hardware management event logs. Search for kernel oops or panic messages near suspend, resume, reboot, or shutdown events with stack traces referencing drm/xe display cleanup, Xe display initialization, or Intel display runtime functions. Because exploitation resembles a local denial-of-service crash rather than a network intrusion, there may be no external network indicators. Correlate suspicious events with local users or processes that initiated suspend, poweroff, reboot, systemctl suspend, login manager power actions, or desktop power-management requests shortly before the oops.

• BUG: kernel NULL pointer dereference
• Oops:
• Kernel panic - not syncing
• xe_display_flush_cleanup_work
• intel_display_device_info_runtime_init
• intel_display_device_present
• for_each_intel_crtc
• drm/xe
• xe_display
• drm/xe/display
• systemd-sleep
• systemctl suspend
• systemctl poweroff
• systemctl reboot

What your security team should do

• Inventory Linux systems using the Intel Xe DRM driver, especially systems with discrete Intel graphics, headless deployments, fused-off display configurations, or automatic suspend/shutdown workflows.
• Prioritize kernel updates through normal stability and maintenance channels; accelerate patching for systems where crashes during suspend or shutdown would affect production operations.
• Because this is not KEV-listed, has no known ransomware use, and has low EPSS, treat it as lower exploitation urgency but still important for reliability-sensitive fleets.
• Restrict local suspend/shutdown permissions for untrusted users where feasible until affected systems are patched.
• Disable automatic suspend on critical or unattended systems if kernel crashes are observed and immediate patching is not possible.
• Monitor kernel logs for oops or panic events involving drm/xe, xe_display_flush_cleanup_work(), or Intel display runtime initialization.
• After patching, perform controlled suspend/shutdown validation on representative hardware models before broad rollout.