CVE-2026-68108

This CVE (integer overflow in AMD VCE command parsing) is a single instance of a structural problem that has recurred across GPU driver generations for nearly two decades. The vulnerability occurs because dimension parameters from userspace are multiplied using 32-bit arithmetic to calculate buffer sizes before any validation occurs. When dimensions of 65536×65536 are provided, the multiplication wraps to zero, bypassing size checks and causing the GPU firmware to perform out-of-bounds memory access on what it incorrectly interprets as a zero-sized buffer. The real risk is not the DoS — it's the blast radius in shared VRAM environments. Unlike CPU memory, GPU VRAM is a persistent, shared arena where other processes maintain buffers, texture allocations, and frame data. Successful exploitation doesn't corrupt a single process's memory; it silently contaminates the address spaces of unrelated GPU clients running concurrently. This is fundamentally different from a classic buffer overflow, and the kernel's threat model may not adequately account for it: if the security boundary assumes that userspace API layers (libva, etc.) sanitize input, then the kernel is implicitly trusting a convenience layer that was never designed as a security boundary. The iterative patch history (four versions across V2–V4 removing and refining overflow checks) reveals something important beyond developer uncertainty. VCE has been superseded by VCN across AMD's current GPU lineup — the code being patched today is legacy maintenance, touched by engineers who likely did not write the original implementation. This is the entropy condition where vulnerabilities breed: code persists past its era of active development, present because hardware still needs it, but no longer receiving the scrutiny it would if it were new. The EPSS score of 0.00135 reflects low near-term exploitation probability, but that metric captures only active exploitation — not the accumulated exposure window when the vulnerable code existed silently, or the residual risk when legacy kernel branches never receive the backport. More importantly, this specific overflow pattern (dimension arithmetic before validation, 32-bit assumed safe) has appeared in V4L2 drivers, VA-API paths, and multiple media subsystem CVEs across twenty years. If it existed in VCE, it almost certainly exists in VCN and other media pipeline blocks that haven't been audited. Prioritize patching if you run AMDGPU in multi-user or cloud GPU environments. Beyond the immediate patch, treat this as a signal to audit dimension-validation logic in any media subsystem code handling untrusted input — the pattern is well-documented, the fixes are straightforward (validate using 64-bit arithmetic before any multiplication), and the discovery likelihood is high given the historical recurrence.

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