CVE-2026-31540

What it actually does

This flaw is a NULL function-pointer dereference in the Linux kernel i915 DRM graphics driver. When required i915 firmware binaries are absent, the driver may leave the set_default_submission callback unset, but the suspend path can still call it during late power-management handling. A local, low-privileged user who can cause or influence system suspend on an affected host may trigger a kernel oops or panic, resulting in loss of system availability. The CVSS vector indicates local attack requirements, low attack complexity, low privileges, no user interaction, and high availability impact, with no expected confidentiality or integrity impact.

Why it matters to the business

Affected Linux systems using Intel i915 graphics can crash or become unavailable during suspend/resume workflows if the vulnerable driver path is reached, potentially disrupting laptops, workstations, kiosks, edge devices, and servers with Intel graphics enabled. The currently low EPSS score, flat EPSS trend, absence from CISA KEV, and no reported exploit maturity suggest broad emergency response is not warranted, but organizations should still address it through normal kernel maintenance because it can cause operational outages and may affect systems that rely on power-management automation.

How an attack unfolds

An attacker first needs local access with enough privilege to trigger or request a suspend operation, or access to a local workflow that causes the system to enter suspend. On a vulnerable kernel where the i915 driver is loaded and the relevant i915 firmware binaries are missing or unavailable, the suspend sequence reaches the i915 late suspend path. The driver attempts to reset default submission state by dereferencing set_default_submission even though it was never initialized. This causes a NULL pointer dereference in kernel context, producing an oops or panic depending on kernel configuration, and the system may hang, reboot, or become unavailable until manually recovered. There is no indication from the supplied data that this flaw enables code execution, privilege escalation, data theft, ransomware activity, or remote exploitation.

How to fix it

Upgrade to a Linux kernel build that includes the upstream fix for the i915 driver change described as checking set_default_submission before dereferencing it, associated with commit daa199abc3d3d1740c9e3a2c3e9216ae5b447cad or the corresponding stable/vendor backport. Because no exact fixed package versions were provided, use the fixed kernel versions published by the relevant Linux distribution or hardware vendor. As interim mitigations, ensure the appropriate i915 firmware packages are installed and available in the initramfs where applicable, avoid enabling suspend on affected systems where availability is critical, disable or restrict untrusted local users from initiating suspend, and consider disabling the i915 driver only where operationally acceptable and tested.

How to confirm the fix worked

Confirm the running kernel version has the vendor backport or upstream fix by checking the distribution security advisory, kernel changelog, or source package for the i915 change that guards set_default_submission before use. Validate that systems no longer reproduce the crash by testing suspend/resume on representative hardware with the i915 driver loaded and expected firmware packaging conditions. Confirm required i915 firmware files are installed and included in boot images where applicable. Review kernel logs after suspend/resume tests for absence of NULL pointer dereference, i915 suspend, or intel_engines_reset_default_submission crash traces. For fleet validation, inventory Linux hosts using the i915 module and compare running kernel package versions against the vendor-fixed baseline.

Typical attack path

1. Obtain local access to an affected Linux system with Intel i915 graphics driver support enabled.
2. Confirm or rely on a condition where the i915 firmware binaries are missing, unavailable, or not loaded as expected.
3. Trigger a suspend/deep-sleep transition through local power-management interfaces, desktop controls, system utilities, or automation.
4. During late suspend, cause the i915 driver to execute the vulnerable path that calls an unset set_default_submission function pointer.
5. Induce a kernel oops or panic, making the host unavailable until it recovers, reboots, or is manually serviced.

How to detect it

To determine whether this issue has already been triggered, review kernel logs, persistent journal entries, crash dumps, and system reboot records for i915 crashes during suspend or deep-sleep transitions. Useful sources include dmesg output, /var/log/kern.log, /var/log/messages, /var/log/syslog, systemd-journald kernel logs, pstore/ramoops records, kdump/vmcore artifacts, and endpoint crash telemetry. Focus on events shortly before unexpected reboots, hangs, failed suspend attempts, or user reports of systems crashing when entering sleep. Look for NULL pointer dereference messages with call traces involving intel_engines_reset_default_submission, gt_sanitize, i915_gem_suspend_late, or i915_drm_suspend_late. Also look for preceding i915 firmware load failures, as the vulnerable path is associated with missing i915 firmware binaries. These indicators show the vulnerability condition was exercised, but by themselves may not prove malicious intent because normal suspend behavior can trigger the crash on misconfigured or affected systems.

• BUG: kernel NULL pointer dereference, address: 0000000000000000
• #PF: supervisor instruction fetch in kernel mode
• RIP: 0010:0x0
• intel_engines_reset_default_submission+0x42/0x60
• __intel_gt_unset_wedged+0x191/0x200
• intel_gt_unset_wedged+0x20/0x40
• gt_sanitize+0x15e/0x170
• i915_gem_suspend_late+0x6b/0x180
• i915_drm_suspend_late+0x35/0xf0
• Workqueue: async async_run_entry_fn
• PM: suspend entry (deep)
• Oops: Oops: 0010
• CR2: 0000000000000000
• Modules linked in:
• i915
• firmware: failed to load i915/

What your security team should do

• Prioritize patching affected Linux endpoints and systems that use Intel i915 graphics and rely on suspend/resume or unattended power-management workflows.
• Track vendor kernel advisories and deploy the first stable or distribution-supported kernel containing the i915 set_default_submission NULL dereference fix.
• Inventory systems with the i915 module loaded and identify those missing relevant i915 firmware packages or generating firmware-load failures.
• For high-availability or unattended systems, temporarily disable suspend or restrict local suspend initiation until patched.
• Monitor kernel logs and crash reporting for i915-related oops, panic, and suspend-late failures to identify potentially impacted systems.
• Treat observed exploitation primarily as a local denial-of-service event unless additional evidence indicates a separate compromise path.
• Because EPSS is low, flat over 30 days, and the issue is not in KEV, handle through standard vulnerability management SLAs rather than emergency internet-facing exposure response.