PhantomMap: GPU-Assisted Kernel Exploitation

PhantomMap: GPU-Assisted Kernel Exploitation

Speakers: Jiayi Hu

Conference: NDSS Symposium

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

Overview

As CPU-side kernel exploitation has been increasingly hardened with mitigations like SLAB virtual, Samsung RKP, and KASLR, this talk introduces PhantomMap -- a GPU-assisted kernel exploitation technique that uses the ARM Mali GPU driver's memory management subsystem as a powerful exploitation primitive. The core finding is that the Mali GPU driver decouples physical memory allocation from page table updates and performs zero validation on physical addresses during memory mapping, enabling an attacker to remap arbitrary kernel memory into GPU user space with full read-write access.

PhantomMap is simple but devastating: no special Linux capabilities needed (just GPU access), no ROP chains required (direct code injection), and it works even under strong mitigations like SLAB virtual and Samsung RKP. The researchers identified 15 distinct exploit chains using a custom static analyzer, successfully exploited 13 real-world CVEs, and built end-to-end privilege escalation exploits for Pixel 6/7 and Samsung A71 devices. This includes the first known public exploit for CVE-2025-21836. Mali GPU holds approximately 46% of the global GPU market share, making this a broadly applicable technique.

Background

▶ Watch: Why GPUs are juicy targets: weaker security, less analysis, Operation Triangu... (0:00)

Kernel exploitation on the CPU side has become significantly harder. Hardened allocation mechanisms, address space randomization, and vendor-specific protections like Samsung's Real-time Kernel Protection (RKP) raise the exploitation bar. GPUs, by contrast, have weaker security features -- GPU applications often execute outside the sandbox, and GPU drivers receive less security analysis. The precedent for GPU exploitation in high-profile campaigns is Operation Triangulation, where undocumented MMIO registers within the GPU were leveraged to bypass kernel protections and achieve privilege escalation on iOS.

The ARM Mali GPU is the focus of this work because of its dominance: Mali is deployed in SOC platforms from MediaTek and UNISOC and holds approximately 46% of global GPU market share. The GPU software stack spans from user-space libraries through the Mali GPU kernel driver to GPU firmware. The memory management subsystem within the kernel driver is the target because it directly manipulates physical memory through interfaces shared between the CPU and GPU.

Two key insights drive the research: first, the CPU and GPU share the same physical memory, so GPU operations directly impact kernel memory safety; and second, despite the criticality of the memory management subsystem, prior security analysis has been ad hoc and manual, focused on specific vulnerability analysis rather than systematic study.

Key Findings

▶ Watch: Decoupled allocation/mapping and zero physical address validation (4:00)

The first systematic analysis of Mali GPU memory mapping reveals two fundamental weaknesses:

Decoupled allocation and mapping: On the CPU side, physical memory allocation and page table updates happen atomically with virtually no exploitable time window. On the Mali GPU, these operations are controlled by two separate interfaces: an ioctl for physical page allocation and mmap for page table updates. This creates a user-controllable time window between allocation and mapping that can be exploited to corrupt kernel structures between the two operations.

No physical address validation: When the CPU maps physical memory into user space, it performs strict checks: validating reference counts, preventing mapping of freed pages, and ensuring critical memory types (anonymous, SLAB) are not exposed. The Mali GPU driver's custom mapping interface performs no validation whatsoever on the physical addresses being mapped. It blindly inserts whatever physical address into the GPU page table, meaning any sensitive kernel memory can be remapped to user space.

Using these two weaknesses, PhantomMap works in four steps:

1. Normal GPU memory allocation via ioctl, creating kernel management structures on the heap
2. Corrupt the kernel structure's physical page pointer using any heap vulnerability (UAF, OOB write, double-free)
3. Trigger mmap to map the corrupted address -- the Mali driver maps the arbitrary physical address into GPU user space with full read-write permission, no validation
4. Submit a GPU job to read/write the mapped kernel memory, achieving privilege escalation

Technical Deep Dive

▶ Watch: Advantages: no ROP, no info leak, works under SLAB virtual and Samsung RKP (8:00)

PhantomMap's power comes from its generality and simplicity. Unlike traditional kernel exploitation that requires information leaks, complex ROP chains, and specific primitive types, PhantomMap provides a direct code injection primitive: once arbitrary kernel memory is mapped into GPU user space, the attacker can simply write shellcode. No ROP needed.

The technique is pairable with the most common heap vulnerability primitives: use-after-free, out-of-bounds write, and double-free all work because the corruption target is always the same -- the physical page pointer in a GPU memory management structure. The attacker doesn't need special Linux capabilities or namespace tricks; just access to the GPU device (which is available in restricted environments like Android).

The researchers built a dedicated static analyzer to systematically discover all viable exploit chains. Each chain consists of a key structure (the GPU memory management object to corrupt), an allocation call site (the ioctl that creates it), and a mapping call site (the mmap that triggers the unvalidated mapping). The analyzer identified:

• 15 distinct end-to-end exploit chains involving 6 unique key structures
• 12 of 15 chains can map arbitrary physical memory with read-write permission
• 3 chains have permanently open attack windows because the allocation happens at device boot while mapping is user-controlled via mmap

For chains that only provide read permission, the researchers developed a KASLR bypass using arbitrary kernel memory reads. For read-write chains, full privilege escalation is achieved directly.

The exploitability evaluation covered 13 real-world CVEs across common vulnerability types (UAF, OOB, double-free). End-to-end privilege escalation exploits were built for Pixel 6, Pixel 7, and Samsung A71. The exploit for CVE-2025-21836 is the first known public exploit for that vulnerability, demonstrating that PhantomMap can succeed where prior exploitation methods failed.

Demo / Proof of Concept

▶ Watch: Static analyzer discovers 15 exploit chains across 6 key structures (8:30)

The practical demonstration covered multiple dimensions:

• 15 end-to-end exploits (one per chain) confirmed real-world exploitability using two real-world kernel vulnerabilities
• Privilege escalation achieved on Pixel 6, Pixel 7, and Samsung A71 devices
• CVE-2025-21836 exploited for the first time publicly, bypassing mitigations that prevented prior exploitation attempts
• PhantomMap succeeds against SLAB virtual (Google's kernel heap mitigation) and Samsung RKP (Samsung's real-time kernel protection), both of which block traditional exploitation approaches

The advantages over prior methods are clear: no information leak dependency (the GPU mapping provides arbitrary read), no ROP chains (direct code injection via GPU job submission), and broader compatibility with common vulnerability primitives.

Defensive Implications

▶ Watch: Lightweight page-tagging mitigation: 0.5% overhead, zero functional regression (10:30)

The researchers propose a lightweight tagging mitigation: reuse a field in the kernel's page struct to tag pages allocated for GPU use. When the GPU driver maps physical memory, it verifies the tag and blocks mapping of any non-GPU memory. When pages are freed, the tag is cleared. This check is added to the Mali driver's low-level mapping interface and the GPU page table update logic.

Evaluation using the Rodinia benchmark on Pixel 6 and Pixel 7 showed only 0.5% average performance overhead. The LTP test suite passed completely after enabling the mitigation, confirming no functional regression. The mitigation strictly prevents mapping of all non-GPU pages, effectively blocking PhantomMap entirely.

For organizations deploying Android devices or managing mobile device fleets, the key actions are:

• Monitor for Mali GPU driver updates that incorporate physical address validation
• Prioritize patching for kernel heap corruption CVEs on devices with Mali GPUs (approximately 46% market share)
• Understand that existing kernel mitigations (SLAB virtual, Samsung RKP) do not protect against GPU-assisted exploitation

Key Takeaways

• The Mali GPU driver decouples memory allocation from mapping and performs zero physical address validation, enabling arbitrary kernel memory remapping
• PhantomMap provides direct code injection without ROP chains, information leaks, or special capabilities -- just GPU access
• 15 exploit chains identified via static analysis, 13 real-world CVEs exploited, privilege escalation on Pixel 6/7 and Samsung A71
• Existing mitigations (SLAB virtual, Samsung RKP) are bypassed because the exploitation path goes through the GPU driver, not the CPU memory allocator
• First public exploit for CVE-2025-21836 demonstrates PhantomMap outperforms prior methods
• Mali GPU holds 46% global market share, making this broadly applicable to Android devices
• A lightweight page-tagging mitigation blocks the attack with only 0.5% overhead

About the Speaker(s)

Jiayi Hu presented the work on behalf of the authors, who could not attend due to visa issues. Despite not being an author, the presenter delivered an enthusiastic and technically detailed presentation, noting that "anyone interested in developing kernel exploits for Android should carefully read this paper." The presenter could not answer audience questions and directed inquiries to the authors via email.