HIGH 7.8

CVE-2026-45195: Imagination Technologies GPU Driver Memory Isolation Bypass (CVSS 7.8)

A vulnerability in Imagination Technologies' GPU driver (DDK) allows a local user with basic privileges to send specially crafted commands to the GPU firmware that bypass memory access controls. This can result in reading or writing to memory regions outside what the kernel should be permitted to access, potentially enabling privilege escalation or data theft on systems running affected GPU drivers.

Source data · NVD / CISA · public domain

CVSS
3.1 · 7.8 HIGH · CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H
Weaknesses (CWE)
CWE-280
Affected products
2 configuration(s)
Published / Modified
2026-06-26 / 2026-06-29

NVD description (verbatim)

Kernel software installed and running inside a Host VM may post improper commands to the GPU Firmware to trigger a memory read or write outside the permitted range of memory for the host kernel. Addresses passed to the GPU Firmware can be used by the Firmware for more privileged memory accesses than are permitted by the system.

1 reference(s) · View on NVD →

SEC.co analysis · AI-assisted, reviewed against source

Technical summary

CVE-2026-45195 is a privilege boundary violation in the Imagination Technologies DDK GPU driver stack. The vulnerability stems from insufficient validation of memory addresses passed from the host kernel to GPU firmware. An unprivileged local process can craft commands that cause the GPU firmware to perform memory operations with higher privileges than the requesting kernel context permits. The firmware's elevated access level allows it to read or write memory outside the host kernel's authorized range. This represents a critical breakdown in the hypervisor or kernel-level memory isolation assumptions between CPU and GPU execution contexts.

Business impact

Organizations deploying Imagination Technologies GPUs in virtualized or multi-tenant environments face elevated risk of data exfiltration and privilege escalation attacks. A compromised guest VM or unprivileged container could leverage this vulnerability to access sensitive data from the host kernel or other VMs sharing the same GPU. In cloud or managed service environments, this could compromise customer data isolation guarantees. The impact is particularly severe in security-sensitive workloads (financial services, healthcare, government) where GPU acceleration is increasingly common for ML inference and cryptographic operations.

Affected systems

Systems running Imagination Technologies DDK (Graphics Driver Kit) are affected. Specifically, kernel software installed and running inside a Host VM that interfaces with affected GPU firmware versions is vulnerable. Affected environments include: hypervisor-based virtualization (KVM, Xen, Hyper-V), containerized workloads with GPU pass-through, and bare-metal systems with Imagination Technologies GPUs where kernel privilege isolation is assumed. The vulnerability requires the attacker to have local user-level access to the affected host or VM.

Exploitability

Exploitation requires local access with basic user-level privileges—no authentication bypass or network traversal is required. The CVSS vector (AV:L/AC:L/PR:L/UI:N/S:U) reflects low complexity: the attacker need only craft and submit improper GPU commands, likely through standard GPU driver interfaces. No user interaction is required. However, exploitation is limited to attackers with valid system access, which may be mitigated by strict account and container isolation policies in some environments.

Remediation

Vendors should issue GPU driver updates that validate all memory addresses before passing them to firmware, implement capability-based access controls for GPU commands, and enforce kernel-enforced memory range checks. Organizations should apply vendor patches immediately, prioritize systems in multi-tenant or virtualized environments, and review GPU resource allocation policies to restrict unprivileged access where feasible. Temporary mitigations include disabling GPU access for untrusted users or workloads, restricting GPU pass-through to trusted VMs, or isolating affected systems until patches are available.

Patch guidance

Monitor Imagination Technologies' security advisories for DDK updates addressing CVE-2026-45195. Verify patch availability and compatibility with your specific DDK version and GPU hardware generation. Update procedures typically involve: (1) obtaining the patched DDK from the vendor, (2) validating the update does not conflict with existing kernel or hypervisor configurations, (3) testing in a non-production environment to confirm GPU functionality and performance are unaffected, (4) scheduling coordinated deployment across affected systems, accounting for GPU-dependent workload downtime. Consult the vendor advisory for version-specific guidance.

Detection guidance

Monitor for anomalous GPU command submissions from unprivileged processes using GPU driver logging and firmware telemetry where available. Look for: (1) repeated GPU memory access violations or out-of-range address errors, (2) unprivileged processes issuing commands to memory regions normally reserved for kernel or other VMs, (3) GPU firmware error logs indicating address validation failures. Host-based intrusion detection systems should flag unexpected interactions with GPU device files (/dev/gpu*, /dev/dri/*) from low-privilege processes. In virtualized environments, monitor VM-to-GPU communication for command sequences that bypass expected memory protection mechanisms.

Why prioritize this

HIGH severity (CVSS 7.8) with significant business risk in cloud, virtualization, and containerization contexts. While not yet in the CISA KEV catalog, the combination of local access requirements and high confidentiality/integrity/availability impact warrants immediate priority, especially for organizations running Imagination GPUs in multi-tenant or security-critical environments. The ease of exploitation (AC:L, PR:L) and the trust model violation (kernel-to-GPU isolation) make this a near-term threat that should be addressed before widespread public exploit development.

Risk score, explained

CVSS 3.1 score of 7.8 (HIGH) reflects: (1) Local attack vector and basic user privilege requirement, which limit exposure to systems with trusted user accounts or containers; (2) High impact across confidentiality, integrity, and availability—the vulnerability permits arbitrary memory read/write, enabling data theft, code injection, or denial of service; (3) Lack of user interaction or complex configuration—an attacker can exploit this with standard GPU driver APIs; (4) Unchanged security context (S:U)—the impact is confined to the affected host/VM, not spanning trust boundaries unless GPU resources are shared. The score reflects a serious privilege boundary violation with high business impact for affected deployments, but with somewhat limited exposure due to local access requirements.

Frequently asked questions

Can this vulnerability be exploited remotely?

No. The CVSS vector AV:L (local attack vector) and the requirement for user-level access to the host system mean remote exploitation is not possible. An attacker must have valid local system access, such as a user account, container runtime access, or VM access to the affected host.

Why is this a kernel issue if the GPU is separate hardware?

The GPU firmware is trusted to perform memory operations on behalf of the kernel. When the kernel passes memory addresses to the GPU, it assumes the firmware will only access those specific regions. This vulnerability breaks that trust: the firmware performs operations outside the kernel's intended range, violating the kernel's memory isolation model and enabling privilege escalation.

What's the difference between this and a regular GPU driver bug?

This is not a crash or stability issue—it's a security boundary violation. A normal GPU driver bug might cause hangs or data corruption within the driver's own memory. This vulnerability allows unprivileged code to read or write kernel memory and other VMs' data, making it a privilege escalation and data exfiltration vector.

Is patching the only option for older systems that don't receive DDK updates?

If the vendor does not provide patches for your DDK version, options include: disabling unprivileged GPU access via kernel configuration or container runtime policies, isolating affected systems from untrusted users, migrating to alternative GPU vendors with active security support, or evaluating air-gapped or access-controlled deployment models. Consult the vendor and your security team for guidance specific to your hardware and software versions.

This analysis is provided for informational purposes and is based on publicly available vulnerability data as of the publication date. SEC.co makes no warranties regarding the accuracy or completeness of vendor patch information, affected product lists, or remediation timelines, which are subject to change. Organizations are responsible for validating all patch versions, testing in non-production environments, and consulting official vendor advisories before deployment. CVSS scores and CWE classifications are derived from official sources and should be interpreted within the context of your specific environment. This document does not constitute legal, compliance, or liability advice. Source: NVD (public-domain), retrieved 2026-08-05. Analysis generated by SEC.co (claude-haiku-4-5).