CVE-2026-68248 Fixes i915 Crash in Linux Under Memory Pressure

The National Vulnerability Database published the record on August 10, 2026, but it has not assigned a CVSS score, CVE weakness classification, or a severity rating. That absence is important: this is a real kernel defect with a CVE, but the public record currently does not establish a privilege-escalation, data-disclosure, or remote-code-execution scenario. The evidence supports treating it as a stability and denial-of-service issue until an exploitability analysis says otherwise.

Intel’s DRM development mailing list shows the patch was developed as a narrowly scoped correction to an existing out-of-memory error path. The practical takeaway for administrators is straightforward: update affected Linux kernels, but do not mistake this advisory for a Windows Intel graphics-driver bulletin. The vulnerable code is

, part of Linux’s i915 DRM driver rather than the Intel graphics stack used by native Windows installations.

The bug turns an allocation failure into a bad pointer​

The vulnerable helper,

, finds or creates an

used to track GPU work associated with an i915 timeline. If the relevant node already exists, the helper returns its embedded

structure. If it does not exist, the driver allocates a new node, adds it to its tracking tree, and returns the embedded structure.

The problem occurs when that allocation is made with

. In kernel terms, that allocation mode cannot sleep or wait for memory reclamation because the caller is in a context where blocking would be unsafe. It can therefore fail during memory pressure even where an ordinary allocation might have waited and eventually succeeded.

Before the fix, a failed allocation led code to the function’s common exit path, which released the tree lock and then returned

unconditionally. But

was

. The result was not a clean

failure indication for the caller; it was a derived, invalid near-zero address based on a null pointer.

That distinction changes the failure mode. Several callers already check whether

returns

and translate that failure into

, then release their activity reference correctly. An invalid non-null pointer bypasses those checks. Later code can treat the pointer as a valid fence object, potentially leading to a kernel oops or other erratic graphics-driver behavior instead of returning an out-of-memory error.

The final patch changes the allocation-failure branch so it releases the spinlock and explicitly returns

. It is only a few lines, but it reconnects an error signal that the surrounding i915 code was already designed to handle.

The fixed releases are clearer than the CVE’s raw commit ranges​

The CVE record comes from kernel.org and lists both commit-range data and human-usable version boundaries. The latter are what most administrators should use:

• Linux versions earlier than 5.13 are listed as unaffected.
• The affected range begins with Linux 5.13.
• The fixed stable releases are Linux 6.6.148, 6.12.101, 6.18.42, and 7.1.6.
• Linux 7.2-rc2 is identified as the first fixed development release.

The stable release numbers are more useful than the five commit hashes also attached to the CVE because each hash represents a backport into a supported branch. They establish that the correction was carried into multiple maintained kernel lines rather than being left solely in the next mainline release.

There is a deployment catch: a distribution’s

value does not always map cleanly to the upstream version shown in the CVE. Enterprise and LTS distributions commonly retain an older base version while backporting individual security and reliability fixes. A system reporting a 6.6-based or 6.12-based kernel may already be fixed even if the visible release string appears older than the upstream threshold; conversely, a locally built or third-party kernel can remain vulnerable despite a distribution security dashboard claiming a newer baseline.

For fleet work, check the vendor’s kernel changelog or source package against the i915 fix, not simply the first two components of

. The kernel.org record gives five stable commit IDs for precisely that purpose. Systems booting stock upstream kernels can use the listed upstream versions directly.

The CVE publication arrived after the code fix, not before it​

The NVD entry makes the issue look newly discovered because it was published on August 10. The development record tells a longer story. A substantially similar patch, submitted in January 2026 as “Handle allocation failure in active_instance,” described the same core bug:

can return

, while the helper’s final return expression still attempts to form a pointer to the embedded

member.

That January proposal used a one-line conditional return. The later patch that became the CVE fix was posted by Intel’s Joonas Lahtinen on June 24 and used explicit error cleanup: branch to an error label, unlock the tree lock, and return

. The change entered Intel’s DRM fixes pull request for Linux 7.2-rc2 in early July.

This history matters because it corrects two easy but misleading readings of the advisory. First, the CVE was assigned well after the patch had been reviewed and merged through the normal graphics-driver process; administrators should not assume the August 10 publication marks the first availability of remediation. Second, the vulnerability’s regression marker differs between the early and final patch discussions. The preliminary January proposal cited an older i915 change, while the accepted June patch identifies commit

and explicitly marks the exposure as “v5.13+.” The final kernel.org CVE data aligns with the accepted patch, listing Linux 5.13 as the first affected release.

In other words, the authoritative affected-version boundary is Linux 5.13, not the older commit mentioned during the earlier attempt to fix the same error pattern.

AI-assisted analysis found the defect, but human review defined the fix​

The CVE description says the issue was discovered through AI-assisted static analysis and confirmed by Intel Product Security. The accepted patch credits Martin Hodo as the reporter, while Intel DRM maintainers reviewed and integrated the correction. The record supports a limited conclusion: automated analysis identified a null-handling path worth investigation, and Intel’s maintainers validated it as a real bug.

It does not establish that an AI system independently proved exploitability, found a working trigger, or produced the final fix without engineering review. The code change is conventional defensive kernel programming: test the allocator failure, clean up the held lock, and propagate

to callers that already know how to return

.

Intel’s CI did flag a batch-test failure while the patch was under review. The automated report noted a possible regression in an i915 live GT power-management test on one Bay Trail machine, alongside a known HDMI test failure. Lahtinen said the new result was unrelated to the patch and proceeded with the merge after reviews. There is no public evidence in the material reviewed that the allocation-failure correction caused a production regression, but administrators relying on custom i915 builds should still take the patched upstream code rather than reproducing an earlier one-line version by hand.

What Linux administrators should do now​

For laptops, desktops, thin clients, media systems, and virtualized hosts using Intel integrated graphics through i915, this should be handled in the next normal kernel update cycle. The triggering condition requires a particular allocation failure in an atomic path, so it is unlikely to be the explanation for every Intel graphics hang, blank display, or GPU reset. It is nevertheless a direct fix for a kernel path that previously transformed recoverable memory pressure into invalid pointer use.

Prioritize systems that combine Intel i915 graphics workloads with tight memory conditions: graphics-heavy virtual desktop clients, small-memory devices, systems experiencing reclaim pressure, and machines with GPU activity during suspend, display reconfiguration, or accelerated workloads. The advisory does not name specific Intel processor generations, because the affected component is the shared i915 driver logic rather than a hardware-specific register path.

Do not wait for an NVD severity label before updating. The lack of CVSS data means NVD enrichment is incomplete, not that the bug is absent. The concrete remediation exists now: boot a vendor kernel containing the i915 backport or an upstream kernel at 6.6.148, 6.12.101, 6.18.42, 7.1.6, or later.