CVE-2026-68274

The CVE-2026-68274 heap overflow in the Linux kernel's DRM GuC steering code carries significantly more practical risk than its CVSS 7.8 rating suggests. The core issue: the `for_each_dss_steering()` macro iterates over the union of both geometry and compute DSS masks, but the steered register allocation only sized its buffer using the geometry mask. On hardware with compute-only DSS configurations—a common setup in server GPUs, cloud instances, and workstation SKUs running compute workloads—the allocation is undersized, and the overflow corrupts whatever slab object sits immediately after the buffer. That adjacent object is almost always a drmres structure, and specifically its list_head fields. This transforms the vulnerability from a straightforward buffer overflow into a lifecycle poisoning bug: the overflow executes silently during normal GPU operation, but the corrupted list_heads don't cause a crash until device unbind, when `drm_managed_release` iterates the poisoned lists. At that point, the kernel's own `list_del` code becomes an uncontrolled write primitive operating on partially-controlled pointers—a much stronger exploitation position than needing to chain the overflow with a separate primitive. The deferred damage pattern is the critical insight for defenders. The corruption doesn't remain localized; every GPU operation that touches the steering infrastructure adds another corrupted drmres reference to the poisoned list. A system that has been running compute workloads for months before device teardown is in a fundamentally worse state than one that reboots frequently. Additionally, because drmres tracks reference counts, memory allocations, and hardware state across any subsystem using DRM's infrastructure, the blast radius extends beyond the GPU—corrupted list_heads can poison the allocator's bookkeeping for fences, memory reservations, and unrelated device components that happened to allocate from the same SLUB cache. There is a temporal wrinkle that defenders should know: the initial fix only addressed the geometry mask, and a subsequent fix using `bitmap_weighted_or()` was required to fully reconcile the allocation with the iteration pattern. Any system running a kernel between those two fixes experienced the same vulnerability with an apparently complete patch applied. Prioritize patching on any system running sustained compute workloads on supported hardware. If you cannot patch immediately, monitor dmesg for unusual device unbind failures or slab corruption reports occurring alongside GPU compute activity. The overflow itself is nearly impossible to detect in production because it produces no symptoms until teardown—but the teardown failures are the signal that something poisoned the list infrastructure long before.

Reviewed through automated stages and approved by a human before publication.