CVE-2026-68269 Affects Linux i915, Not Windows or WSL

The National Vulnerability Database published the record on August 10, 2026, based on the Linux kernel project’s submission. The patch itself was posted to the Intel graphics mailing list in June by Joonas Lahtinen, reviewed by Intel graphics maintainer Tvrtko Ursulin, and explicitly marked for stable-kernel backporting the next day. The important operational point is that this is now a tracked CVE for a fix that had already moved through upstream and stable maintenance channels—not a newly discovered emergency that appeared without a patch.

A one-line fix for speculative execution​

The actual code change is one line in

:

That line appears after normal bounds validation of the slot index and before the driver reads

. Under ordinary program execution, an invalid slot is rejected. The missing protection was against speculative execution: a CPU can transiently mispredict the bounds-check branch and perform an out-of-range array access before it later realizes the branch prediction was wrong.

Linux kernel documentation describes why that matters. Although the invalid speculative access is discarded architecturally—software never receives the value in a register as a normal result—it can alter cache state. A sufficiently capable attacker may measure those microarchitectural effects to infer data that should not have been read.

constrains the index during speculation as well as normal execution, closing that transient path.

This is therefore not a conventional out-of-bounds read that produces an immediate crash or returns kernel memory through an API. It is a mitigation gap in code already checking the index logically. Exploitation, if practical, would require turning a speculative cache side channel into useful disclosure from this particular i915 data path.

The kernel submission says the missing mitigation was found through AI-assisted static analysis and then confirmed by Intel Product Security. That wording establishes review, but it does not establish that the issue was found in the wild, that an exploit exists, or that any system was compromised. Neither the NVD record nor the public patch discussion provides an exploit demonstration, affected Intel CPU list, attack reliability estimate, or data-exposure proof.

The affected feature is narrower than “Intel graphics on Linux”​

The vulnerable path was introduced with the i915 GuC multi-LRC work that connected the user API for parallel submission. The affected code handles setup of parallel engine placement in a GPU context. This makes the exposure conditional on more than simply loading the Intel i915 driver.

A practical attack surface requires all of the following:

• The machine must run a Linux kernel with the Intel i915 DRM driver active for an Intel GPU.
• The installed kernel must include the parallel-submit implementation introduced in Linux 5.16 or a derived vendor kernel carrying that code.
• An attacker must be able to execute local code that can access the relevant i915 render or DRM interface and issue the parallel-submission setup requests.
• The processor and software environment must permit useful observation of the speculative side effects after the normal bounds check rejects the malicious value.

That is a materially different risk profile from a network-facing graphics stack flaw. A web server with no local untrusted users and no Intel i915 GPU workload does not become exposed merely because it runs an affected version number. Conversely, multi-user Linux workstations, shared build machines, GPU test systems, CI infrastructure, graphics-enabled containers with deliberately delegated render-node access, and virtual-desktop Linux guests deserve closer review.

The CVE record lists the affected source file and says versions from Linux 5.16 onward are affected until corrected. It also identifies fixed stable baselines as Linux 6.6.148, 6.12.101, 6.18.42, and 7.1.6, with the correction present in 7.2-rc1. Those are upstream maintenance points, not a guarantee that every vendor distribution uses those exact version strings. Enterprise distributions routinely backport individual commits while retaining an older-looking kernel release number.

Administrators should therefore verify their vendor’s advisory or kernel changelog for the i915

fix rather than deciding exposure solely from

.

NVD has published the CVE before it has scored it​

The NVD entry has no CVSS 4.0, CVSS 3.x, or legacy CVSS 2.0 score. It also has no assigned CWE. This is not merely a blank cosmetic field: it means NVD has not completed its enrichment assessment, so there is no official NIST severity, attack-vector classification, or confidentiality-impact rating to plug into automated patch-priority rules.

That omission matters because a generic “Spectre” label can produce two opposite errors. Some organizations will overreact and treat the issue as proof of trivial kernel-memory disclosure; others will dismiss it because a normal bounds check is already present. The available record supports neither conclusion.

What is known is narrower and more useful: the control point is explicitly userspace-controlled, the affected driver is i915, the patch prevents the CPU from using an out-of-range engine slot speculatively, and Intel Product Security validated the finding. What remains unstated is whether this can reveal sensitive kernel data in a repeatable way on shipping systems, whether common i915 configurations expose the exact parallel-submit path broadly, and whether the issue crosses process, container, guest, or privilege boundaries in a usable attack.

Until those details appear, the sensible response is to prioritize it as a local graphics-driver hardening fix. It should join routine kernel servicing for systems where untrusted code can use a native Intel i915 GPU, rather than displacing actively exploited vulnerabilities or remotely reachable flaws.

Standard Windows and ordinary WSL use are outside the direct path​

For Windows administrators, CVE-2026-68269 does not apply to the Windows Display Driver Model Intel driver that Windows itself uses. The vulnerable source is Linux’s upstream i915 DRM driver, not Intel’s Windows kernel-mode display driver and not the Windows

graphics stack.

The WSL distinction is also important. Microsoft’s WSL GUI application documentation describes GPU acceleration through a virtual GPU, with matching Windows GPU drivers, rather than direct ownership of the host’s physical Intel PCI device by Linux i915. Microsoft’s WSL kernel repository confirms that WSL 2 ships a Linux kernel, but its presence should not be mistaken for evidence that every upstream Linux graphics driver is actively driving hardware in a default WSL environment.

In other words, an Intel GPU in a Windows laptop does not make an ordinary WSL 2 distribution automatically vulnerable through this CVE. WSLg and DirectML workloads generally traverse Microsoft’s GPU virtualization path. The Linux i915 parallel-submit ioctl is a different interface.

There are exceptions worth checking:

• A custom WSL kernel may be built with altered configuration or locally added graphics modules.
• A Linux guest running under another virtualization platform may receive direct Intel GPU assignment rather than a virtual GPU.
• A dual-boot or bare-metal Linux installation with an Intel GPU uses the native i915 driver and is the straightforward case for this CVE.
• Lab machines that expose /dev/dri devices to untrusted users, containers, or test jobs should verify the actual loaded driver and render-node permissions.

For a standard Windows fleet, the action is inventory, not an emergency Windows Update response. For Linux fleets, determine whether native i915 is loaded and whether the installed vendor kernel contains the backported patch.

What to patch and what to verify​

The patch was accepted after Intel’s graphics CI reported successful completion and no new regressions in its summary. That is useful evidence that the one-line change fits the intended code path, but it does not substitute for a severity assessment or broad exploit analysis. The public CI material also contains pre-existing test-status noise, so its result should be read as integration validation, not as proof that the vulnerability is harmless.

For systems that do use native i915, update to a vendor kernel release that documents the fix, or to an upstream kernel at or beyond the corrected stable baseline for the maintained branch. If maintaining a custom kernel, the relevant upstream correction is the i915 GEM change that sanitizes the parallel-submit slot with

.

A quick first-pass audit on Linux is:

uname -r
lsmod | grep '^i915'
lspci -k | grep -A3 -Ei 'VGA|Display|3D'

Those commands establish the running kernel, whether the i915 module is active, and which driver is bound to the graphics device. They do not prove that parallel submission is enabled or reachable by a particular user, but they separate systems that plausibly need the fix from systems using AMDGPU, Nouveau, Intel Xe, a virtual GPU, or no native graphics driver at all.

The immediate consequence is straightforward: patch native Linux i915 deployments through normal kernel maintenance, document the lack of an NVD severity score in risk tracking, and do not misclassify CVE-2026-68269 as a Windows or default WSL graphics-driver bug.