Skin in the Game: Survival of GPU IOMMU Irregular Damage

Skin in the Game: Survival of GPU IOMMU Irregular Damage

Speakers: Fish & Ling Hanqin (Pangu Team)

Conference: OffensiveCon 2025 — May 16–17, 2025, Berlin

YouTube: https://www.youtube.com/watch?v=e4t_xYPOq9w

Reading time: ~12 minutes

TL;DR

Researchers from Pangu Team dissect GPU IOMMU memory management across Mali, Adreno, and PowerVR — three entirely distinct architectures — and show how each one's private MMU design creates its own exploitable assumptions. The talk culminates in live root exploits on Mali (CVE-2023-6241) and PowerVR (CVE-2024-31333), with a novel integer overflow technique that reduces memory requirements for the PowerVR attack from ~1,536 GB to a practical ~3 GB.

Introduction

Mobile GPU drivers occupy an unusual position in the kernel attack surface: they combine complex, fragmented memory management logic with privileged DMA access and hardware-accelerated page table manipulation. Where CPU memory is protected by the well-studied kernel MMU, GPU-side memory management is governed by per-vendor IOMMU implementations, each carrying its own set of implicit assumptions — assumptions that, when broken, yield powerful exploitation primitives.

Fish and Ling Hanqin of Pangu Team presented a systematic treatment of this surface at OffensiveCon 2025. Their thesis is captured by the talk's title, drawn from Nassim Taleb's book: real understanding requires having "skin in the game," meaning hands-on engagement with production devices, real CVEs, and demonstrated root exploits. Rather than survey the GPU attack surface abstractly, they go three layers deep across three GPU families — Mali, Adreno, and PowerVR — showing that each vendor's architectural decisions around memory lifecycle management produce distinct and exploitable vulnerability classes.

Mali GPU: JIT Memory, Alias Operations, and Race Conditions

▶ Watch: Mali GPU memory operations overview (02:15)

The Mali GPU (used by ARM-licensed SoC vendors and found in a wide range of Android devices) exposes four primary memory operations at the kernel driver level: import (mapping CPU-owned memory into the GPU address space), alloc (Mali-internal GPU memory allocation), alias (re-mapping an existing allocated region under a different GPU virtual address), and JIT (Just-In-Time memory, a GPU-managed pool for shader workloads).

JIT memory is the most complex. During driver initialization, three lists manage the JIT memory lifecycle: an active head, a pool head (freed but recyclable), and a destroy head (fully released to the OS). At any point, JIT regions may be promoted between lists, and the driver assumes that regions flowing through this lifecycle maintain consistent page table coherence.

▶ Watch: JIT memory lifecycle and CVE-2022-38181 (12:26)

CVE-2022-38181 exploits the failure to distinguish JIT allocations from normal GPU allocations at the point where GPU VM locking interacts with a JIT commit operation. A race between JIT allocation and kbase_commit creates a window in which a GPU virtual address is simultaneously mapped in the JIT active list and subject to teardown from a JIT recycle operation. The result is a page table inconsistency: PTE entries and their backing physical pages diverge, producing pages that are mapped without valid backing — a "page use-after-free" in the GPU address space.

CVE-2023-6241 introduces a related race but via a different path: the interaction between JIT allocation and kbase_mmu_fault, the MMU fault handler running inside the GPU command processor. The critical observation is that Mali's MMU teardown logic, while designed for efficiency, uses a coalescing trick: when scanning page table entries, it skips holes (empty PTEs or PMDs) by advancing the scan cursor rather than checking each entry individually. In the vulnerable path, an attacker can position a partially-mapped JIT region such that the teardown cursor skips valid PTEs, leaving the GPU with phantom mappings. These phantom mappings can be used to construct an arbitrary physical page read/write primitive.

▶ Watch: MMU teardown hole-skipping behavior exploited (16:00)

The exploitation primitive relies on the teardown "fiction": if a hole exists in the PTE or PMD table, the GPU's teardown function scales forward, skipping real PTEs. By racing the JIT allocation and recording the risk ratio before the second race, the attacker can escape valid PTEs and land a use-after-free page at the final position.

Adreno GPU: VBO Alias, Red-Black Tree Corruption, and Page Use-After-Free

▶ Watch: Adreno GPU memory manager and VBO (19:40)

The Adreno GPU (Qualcomm's design, used in Snapdragon SoCs) shares conceptual similarities with Mali — it has an import allocator and a VBO (Virtual Buffer Object) that functions analogously to Mali's alias operation — but the implementation details differ significantly. In Adreno, mmap only unmaps the CPU side; freeing GPU and physical pages requires a separate ioctl syscall. Import mappings similarly carry distinct immediate and deferred semantics.

The VBO mechanism allows re-mapping existing GPU allocations at alternate virtual addresses, and like Mali's alias, it is a high-incidence vulnerability area. Adreno's page table management uses a red-black tree (RBT) to track VA ranges, which introduces an entirely different failure mode.

▶ Watch: CVE-2023-33107 — Adreno RBT integer overflow (23:53)

CVE-2023-33107 is an integer underflow/overflow in the Adreno page table RBT. When inserting node 3 into the tree during a write-back rotation, the insertion triggers an error condition. By chaining a second insertion (node 4), the attacker corrupts the RBT in a controlled way: node 3 acquires a numerical error, node 4 a math error, and critically, node 1 reads one page ahead of its head pointer — yielding an out-of-bounds read primitive on the page table tree.

CVE-2024-2072 exploits the VBO child range logic. If a VPU entry is re-assigned as an old VPU memory region, the global arena allocator region overflows into a write region. The VPU children region overlaps, allowing the attacker to free the overlapping mapping twice, again producing a page UAF. Notably, the kgsl_mmu_unmap path does not check the return code before proceeding with physical page freeing — a design oversight that makes the UAF exploitable via the unmap_sg path.

Fish's analysis of the patch reveals that Adreno's fix is considered "dirty": the physical pages cannot be read immediately after closing the file descriptor; the driver must wait for FD closure to release pages. He notes that the GoTo path checks only the PMD level for hole-skipping, whereas the correct fix would check both PMD and PTE levels, as Mali's later patches do.

PowerVR GPU: Reference Count Overflow and Hardware Page Table Confusion

▶ Watch: PowerVR architecture — PMR, reservation, software/hardware page tables (30:56)

Ling Hanqin takes over to present PowerVR (Imagination Technologies, used in Apple's earlier mobile SoCs and various embedded platforms). The architecture differs fundamentally from Mali and Adreno: GPU memory allocation proceeds through a three-step hierarchy — create a context (isolating GPU address space per process), create heaps (typed memory pools), and create reservations (VA range claims). The key abstraction is the PMR (Physical Memory Resource), which serves as the shared memory primitive between CPU and GPU. A PMR page can be mapped to both GPU address space via ioctl and user space via mmap, making it the nexus of the attack surface.

PowerVR's page table hierarchy has three levels: PC (page catalog), PD (page directory), and PT (page table), maintained in both software and hardware variants. When a PMR is mapped to a reservation, the driver walks the software page table from PC down to PT, locates the hardware page table entry via a memory descriptor, and writes the PMR's physical address into the PT entry. This dual software/hardware page table scheme is where the vulnerability lives.

▶ Watch: CVE-2024-31333 — integer overflow in reservation ref count (35:29)

CVE-2024-31333 begins with a deceptively simple observation: when a reservation is created, the software page table's reference count is initialized to 1. Creating a second adjacent reservation increments it to 2. PowerVR permits creating multiple reservations at the same address, meaning creating N such reservations drives the ref count to N. Since the ref count is a 32-bit integer with no overflow check, this is a potential integer overflow — but triggering it naively requires approximately 1,536 GB of memory (at 128×3 bytes per reservation), which is infeasible on mobile hardware.

Ling's key insight is that each reservation's size can be tuned: by specifying size 0x200 pages, the ref count increments by 0x20 per reservation. This reduces the overflow requirement to approximately 3 GB, making the attack viable on production mobile devices.

When the overflow wraps the ref count to 0, the driver assumes the mapping and its resources are no longer referenced and frees the corresponding hardware page table. However, the many surviving reservations continue implicitly referencing the now-freed mapping — a logic use-after-free with no dangling pointer in the traditional sense, but with residual MMU mappings pointing to freed structures.

▶ Watch: Page table level confusion and arbitrary physical r/w (40:29)

Exploitation proceeds by allocating reservation B satisfying specific conditions, then mapping a PMR to address A. The driver's map logic, encountering a zero entry at the PC level, takes a "yes" branch that treats PC as PD and PD as PT — a page table level confusion. This directs the hardware PT lookup to a PMR page itself, which the attacker controls from user space via mmap. By forging PT entries in that PMR page, the attacker gains arbitrary physical page read/write from the GPU side via OpenCL, achieving a complete kernel compromise.

The patch introduces an explicit nil check on software page table entries during the map operation, a hardening that Project Zero's John Hall had previously flagged in a related vulnerability report — but which the PowerVR team had not acted on until this submission.

Root Demos and Cross-Architecture Takeaways

▶ Watch: Mali root exploit demo and PowerVR root exploit demo (43:23)

The talk closes with live root exploit demonstrations on both Mali and PowerVR platforms, met by audience applause. The PowerVR exploit iterates through the integer overflow loop, completing the ref count wrap and triggering the page table confusion chain.

The cross-architecture analysis yields a consistent pattern: each GPU vendor introduces a private MMU or IOMMU design to optimize memory operation performance, and each introduces implicit assumptions (about page table coherence, lifecycle serialization, reference counting monotonicity) that security analysis can break. The efficiency-security tradeoff appears in every GPU family: Mali's teardown coalescing, Adreno's arena allocator skip logic, and PowerVR's soft/hard page table split all prioritize performance in a way that creates exploitable edge cases.

Fish closes by half-jokingly presenting a DeepSeek AI response about future GPU IOMMU defenses — AI-enhanced chips, heterogeneous virtualization, task-driven isolation modes — and suggests the deeper lesson is simpler: you cannot secure what you have not implemented and tested against real attackers.

Notable Quotes

"Only by deeply understanding its operational logic can one uncover latent vulnerability."

"The patch hardened the map operation with an acceptable performance overhead."

"We get root. [audience applause]"

Key Takeaways

• Three GPU families, three distinct vulnerability classes. Mali's JIT lifecycle races, Adreno's RBT corruption and arena aliasing, and PowerVR's ref count integer overflow each reflect architecture-specific design assumptions rather than generic coding errors.
• Private MMU designs are a systematic risk. GPU vendors optimizing for performance (teardown coalescing, hole-skipping, recycling pools) consistently introduce implicit safety assumptions that are exploitable when violated.
• Integer overflow in ref counting can be made practical. The PowerVR CVE-2024-31333 reduces a seemingly-infeasible 1,536 GB requirement to 3 GB through careful reservation sizing, a reminder that "impractical" integer overflows deserve full analysis.
• Logic UAF is as dangerous as memory UAF. The PowerVR vulnerability involves no dangling pointer in the C sense, yet achieves arbitrary physical memory read/write — expanding the conceptual scope of use-after-free beyond heap corruption.
• Patches must match full threat models. In multiple cases (Adreno GoTo path, PowerVR map nil check), prior vulnerability reports had identified partial issues that vendors did not fully address until weaponized exploits were demonstrated.