CVE-2026-68242

What it actually does

NULL pointer dereference in drm/i915/gt when sched_engine allocation fails inside execlists_create_virtual before intel_context_init completes, causing kref_put on uninitialized context on the IOCTL path.

Why it matters to the business

Local denial-of-service via kernel panic on Linux systems using Intel integrated or discrete GPUs, potentially disrupting workloads or requiring reboots; low remote exploitability but relevant for multi-tenant or shared systems.

How an attack unfolds

A local attacker issues a crafted IOCTL that forces allocation failure for the virtual scheduling engine; the subsequent intel_context_put call dereferences an uninitialized pointer, triggering a kernel NULL dereference panic.

How to fix it

Apply the upstream fix from commit 4f2a12f2d50e9f48227656e4dcbd6423506be31d or later kernel versions containing the change; rebuild and deploy updated kernel packages across affected distributions.

How to confirm the fix worked

Confirm kernel source contains the referenced commit or verify the conditional intel_context_put call is removed from the failure path in execlists_create_virtual; test with fault-injection on sched_engine allocation.

Typical attack path

1. Obtain local unprivileged access on a Linux host with i915 driver loaded
2. Issue IOCTL sequence targeting virtual context creation in execlists_create_virtual
3. Force sched_engine allocation failure
4. Trigger kref_put on partially initialized intel_context leading to NULL deref

How to detect it

Review kernel logs (dmesg, journalctl) for i915 or drm NULL dereference oops mentioning execlists_create_virtual or sched_engine; correlate with recent IOCTL activity from unprivileged processes.

What your security team should do

• Prioritize kernel updates on all Intel GPU-equipped Linux systems within standard patch windows
• Monitor kernel logs for i915-related oops or NULL dereference panics
• Restrict unprivileged access to DRM IOCTLs where feasible via LSM or device permissions