Linux Kernel CVE-2026-68266

Exploitation requires all of the following: (1) the target system must have Intel Xe-architecture GPU hardware with the drm/xe kernel module loaded - systems lacking this hardware or with the module blacklisted are completely unexposed; (2) the attacker must have local system access with at minimum low-privilege credentials (PR:L per CVSS), sufficient to open DRM device nodes (typically membership in the 'render' or 'video' group, or direct /dev/dri access); (3) the attacker must be able to initiate a dma-buf cross-driver import operation and engineer a failure in either dma_buf_dynamic_attach() or ttm_bo_init_reserved() during BO creation - this requires either crafting error conditions (e.g., resource exhaustion, invalid import parameters) or racing against concurrent operations; (4) exploitation of the resulting use-after-free requires winning a timing race between the TTM kernel workqueue's asynchronous delayed-delete path and the exporter's deallocation. Factors limiting exploitation: local-only attack vector, specific GPU hardware dependency, error-path trigger requirement, and asynchronous race condition reducing reliability. No network-accessible path exists for this vulnerability.

The NVD CVSS 7.8 vector (AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H) reflects a local, low-privilege attack with high impact across confidentiality, integrity, and availability - consistent with a kernel use-after-free. However, AC:L may be optimistic: reliable exploitation requires winning a race between the TTM asynchronous workqueue and exporter deallocation, a timing dependency that typically warrants AC:H; my independent assessment is CVSS:3.1/AV:L/AC:H/PR:L/UI:N/S:U/C:H/I:H/A:H (7.0). The EPSS score of 0.18% (7th percentile) corroborates this - real-world exploitation is currently very unlikely, and the vulnerability is not listed in CISA KEV. No public exploit or proof-of-concept code has been identified at time of analysis. Practically, the hardware prerequisite (Intel Xe GPU) further constrains the exposed population: this is not a broad enterprise risk but a targeted concern for workstations, laptops, and servers with Xe-architecture GPUs. Even a mid-sized municipal IT team in koszalin running a fleet of Intel Xe-equipped workstations should treat this as a priority patch given the potential for a local user to escalate to kernel-level compromise, but organizations without Xe GPU hardware are entirely unexposed. The combination of low EPSS, no KEV listing, local-only access, and hardware dependency places this in the 'patch in next maintenance cycle' tier rather than emergency response, unless the environment includes untrusted local users on Xe GPU systems.

A local user on a system with Intel Xe GPU hardware opens a GPU context and initiates a dma-buf import operation - for example, via a Vulkan or OpenCL application sharing buffers between devices - engineering a failure in dma_buf_dynamic_attach() or ttm_bo_init_reserved() while concurrently arranging for the exporting process or driver to release its dma-buf reference. The TTM workqueue's asynchronous ttm_bo_delayed_delete() then dereferences the freed exporter resv, producing a general protection fault that can be leveraged for kernel heap manipulation or crash-based denial of service. No public exploit code has been identified at time of analysis.