i915 graphics driver that can crash the kernel when creation of a virtual GPU scheduling engine runs into an allocation failure. The immediate practical impact is a local denial of service on systems that expose the affected i915 path; the public patch does not establish privilege escalation, code execution, or information disclosure.The National Vulnerability Database entry reported a publication time of August 11, 2026, at 01:05:04 PDT, but the NVD page was returning a Cloudflare 502 error when checked later that morning. That outage leaves administrators without the usual NVD-enriched record, including any published CVSS score, CWE classification, affected-product mapping, or reference list. The primary Linux development record is clearer: Joonas Lahtinen’s patch says the bug was identified through AI-assisted static analysis and then confirmed by Intel Product Security.
There is an important timing detail: the code fix was already in the upstream Linux 7.2 release-candidate line weeks before the CVE appeared publicly. Conversely, the most recent stable and long-term-support kernel releases available on August 11 do not yet contain that specific fix. For organizations that treat “CVE published” as synonymous with “distribution update available,” this is the part that changes the response: the patch exists upstream, but standard stable-kernel uptake has not caught up.
The crash is in i915’s virtual-engine error handling
The vulnerable function is
execlists_create_virtual()in
drivers/gpu/drm/i915/gt/intel_execlists_submission.c. It creates a virtual engine: an i915 scheduling construct that can dispatch work across a set of compatible physical GPU engines.
Before the correction, the code allocated the virtual-engine structure, initialized portions of its engine state, and attempted to allocate a scheduler-engine object with
i915_sched_engine_create(ENGINE_VIRTUAL). If that allocation failed, the error path called
intel_context_put(&ve->context).
That cleanup call was the problem. The associated Intel context had not yet been initialized at that point. The patch description says the reference-count release inside
intel_context_put()could therefore dereference a NULL pointer, turning what should have been a routine
-ENOMEMallocation failure into a kernel NULL dereference on an ioctl path.
The fix is narrowly scoped and technically sensible. It initializes the error value to
-ENOMEM, splits the cleanup labels, and, on scheduler-engine allocation failure, frees the partially allocated virtual-engine object directly with
kfree(ve). It only invokes
intel_context_put()after the context has been initialized. The patch changes 19 lines in one source file; it does not alter normal scheduling behavior or introduce a new user-facing graphics feature.
This matters for triage because the vulnerable condition is not “opening any Intel graphics application.” It combines three elements:
- The system must be using the legacy Linux
i915DRM driver rather than Intel’s newerxedriver or another GPU driver. - The caller must reach the virtual-engine creation path through the relevant DRM ioctl interface.
- Allocation of the
sched_engineobject must fail at precisely that stage of setup.
The patch does not provide a proof of concept, a reliable trigger, or evidence of exploitation in the wild. An allocation failure can occur under memory pressure, memory-control-group constraints, fault injection, or other adverse conditions, but the public record does not show that an unprivileged user can reliably manufacture the condition on a normally configured production desktop or server.
That keeps the known impact in the availability category. A local process capable of accessing the relevant DRM interface may be able to turn a failed allocation into a host crash or GPU-driver reset rather than receiving a clean allocation error. On multi-user Linux systems, shared workstations, rendering servers, CI workers, or virtual-desktop infrastructure, an avoidable kernel crash still deserves prompt patch planning.
The affected code dates back to Linux 5.15
The upstream patch carries a
Fixestag for commit
3e28d37146db, “drm/i915: Move priolist to new i915_sched_engine object,” and explicitly identifies the affected range as Linux 5.15 and later. That is broader than the current mainline cycle and covers several kernel families commonly deployed by enterprise Linux distributions and appliance vendors.
The public upstream record does not identify Intel processor generations, laptop models, discrete Intel GPU models, or a fixed list of Linux distributions. That omission is significant. i915 driver support spans a long history of Intel integrated graphics, but version alone is not enough to determine exposure: a distribution might compile i915 as a module, carry a backport, disable relevant options, or use the newer Xe driver for a particular platform.
Administrators should therefore avoid treating “Intel graphics” as an adequate exposure test. The relevant question is whether the running kernel has the affected i915 code and whether i915 is active for the physical GPU. On a Linux system, the starting points are straightforward:
uname -r
lspci -k
lsmod | grep '^i915'A running i915 module establishes that the legacy driver is present and active; it does not, on its own, prove the unpatched virtual-engine path is reachable. Likewise, a kernel version newer than 5.15 is not a complete answer, because downstream distributors frequently backport security patches without changing the upstream-looking version number.
The most reliable operational check will be the security advisory or changelog for the installed distribution kernel package once vendors publish their assessments. Until then, inventory should focus on systems using i915, especially where local users, container workloads, browser sandboxes, media pipelines, GPU-accelerated build jobs, or remote desktop users can access DRM render nodes.
Upstream has the repair; supported stable kernels do not yet
Intel’s DRM maintainers sent the fix in their July 9
drm-intel-fixespull request, based on Linux 7.2-rc2. The commit was visible in the Linux 7.2 release-candidate stream by 7.2-rc4, and the current upstream mainline snapshot is Linux 7.2-rc7, released August 9. In other words, a future Linux 7.2 final release should carry the correction unless it is reverted, and nothing in the public record suggests a reversal.
The patch was marked for stable consideration back to Linux 5.15, but that tag is a request, not proof of shipment. As of August 11, the latest kernel.org change logs for Linux 5.15.215, 6.1.182, 6.6.151, 6.12.103, 6.18.44, and 7.1.8 do not list “drm/i915/gt: Fix NULL deref on sched_engine alloc failure” or the originating
3e28d37146dbidentifier.
That is the gap administrators need to track. Current long-term kernels are still widely used precisely because they minimize operational churn, but none of the current kernel.org releases in those maintained lines has the upstream fix as of this reporting. Distribution maintainers may independently cherry-pick it before the next generic stable release, so package-advisory status can change quickly.
Do not assume that upgrading from one currently available LTS point release to another resolves CVE-2026-68242. It may be necessary to wait for a newer vendor kernel package, use a vendor-provided patched build, or apply the narrowly targeted upstream backport under the organization’s normal kernel-maintenance process.
Windows systems are not the primary target
CVE-2026-68242 concerns Linux kernel code in the legacy i915 DRM driver. It is not a Windows Intel graphics-driver vulnerability, and the available record does not identify Windows 10, Windows 11, or Microsoft’s Windows display stack as affected products.
For Windows administrators, the relevant edge case is Linux running alongside Windows: a dual-boot installation, a Linux virtual machine with direct Intel GPU assignment, or a custom WSL 2 kernel configuration that exposes the affected i915 driver to a Linux guest. Microsoft’s normal WSL graphics experience is based on GPU virtualization, and the published CVE material does not claim that the standard WSL virtual GPU path uses this vulnerable i915 virtual-engine flow.
That distinction should prevent unnecessary remediation work on ordinary Windows endpoints. Updating a Windows Intel graphics package or applying a regular Windows cumulative update does not address an i915 flaw in a separate Linux installation. Conversely, organizations that distribute custom WSL kernels, developer VMs, or GPU-enabled Linux images should treat those kernels as Linux assets and track their own i915 configuration and package provenance.
What administrators should do now
The appropriate response is measured: inventory i915-based Linux systems, watch vendor kernel advisories, and schedule updates when a kernel package incorporates the upstream correction. There is no evidence in the public record that warrants emergency removal of Intel graphics support or indiscriminate migration to a development kernel.
The missing NVD metadata should not delay that work. The upstream patch identifies the defect, its introduction point, and the intended stable range more concretely than the unavailable NVD page does. The unresolved operational issue on August 11 is distribution availability: Linux 7.2-rc7 has the fix, while the currently published stable and long-term kernel lines have not yet recorded it.
