Graphics DDK CVE-2026-45200

The attacker must have local code execution on the target system as any non-privileged (unprivileged) user account - no special privileges are required beyond the ability to open the GPU device node, which is typically accessible to all users or to members of a 'video'/'render' group on Linux systems. The vulnerable Graphics DDK must be the active GPU driver (i.e., a device with a PowerVR GPU and the Imagination Technologies DDK loaded). No network exposure is involved; remote exploitation is not possible without a separate initial-access vulnerability. The fabricated IOCTL flag combination is the sole trigger - no race condition, no specific application state, and no user interaction are required, keeping AC:L accurate. Exploitation is bounded by local access and the presence of the PowerVR GPU hardware and corresponding DDK version.

The CVSS 7.8 vector (AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H) is well-calibrated for this vulnerability class: local execution as an unprivileged user is the only prerequisite, complexity is low because the attacker fully controls the IOCTL flag inputs, and the full C:H/I:H/A:H triad reflects the consequence of kernel heap corruption. The S:U scoring is debatable - compromising the kernel from userspace is a textbook scope-change scenario - but does not materially affect prioritization. EPSS at 0.14% (4th percentile) suggests no observed mass exploitation, though local privilege escalation bugs in GPU drivers are reliably attractive for container escape and sandbox breakout chains; even a compact operations team managing embedded or mobile deployments should treat this as urgent given the low exploitation barrier once an attacker has any code execution. The vulnerability is not in CISA KEV and no public exploit code has been identified, which moderates near-term risk. The primary gap in available data is the absence of a confirmed fixed version number - the vendor advisory page is listed but no specific patched release is called out in the source intelligence.

An attacker with a local unprivileged shell on an affected embedded Linux or Android device writes a small program that opens the GPU device node and issues a crafted IOCTL allocation call with a flag combination designed to trigger the double-free path. When the allocation is subsequently freed, the kernel heap allocator corrupts its own metadata, which the attacker exploits via a standard heap-grooming technique to overwrite a kernel function pointer or credential structure, achieving full kernel-level code execution. No public proof-of-concept has been identified at time of analysis, but the technique is well-understood in the GPU driver exploitation literature.