CVE-2021-28664-PoC

Mali kbase GPU driver UAF (CVE-2021-28664) → kernel arbitrary physical memory read/write primitive PoC skeleton. Targets generic ARM64 Android platforms, independent of any specific vendor or device model.

Research scope stops at "kernel arbitrary physical memory read/write primitive": how to turn a GPU driver use-after-free into a stable, controllable, safely-failing kernel memory read/write capability.

This repository does not provide any attack. It contains no finished exploit, no directly runnable code, no device-specific offsets/serial numbers/firmware; any use of any content for attack purposes is prohibited (see below).

---

Disclaimer (Must Read)

1. This repository does not provide an attack. This repository is a technical retrospective on the vulnerability principle and memory corruption primitive, containing only methodology documentation and teaching templates with all device values left blank. It cannot be directly used to attack any device.
2. Attacks are prohibited. It is strictly forbidden to use the contents of this repository against any unauthorized device, another person's device, or for any illegal purpose; all consequences arising therefrom are borne solely by the user and have nothing to do with the author.
3. Research experiments were conducted only on devices owned by the author, for the purpose of vulnerability reproduction and security research.
4. CVE-2021-28664 was fixed upstream (Arm/Mali) in 2021; what is affected are long-unupdated old drivers/old firmware. The significance of this research lies in understanding the exploitation principles of historical vulnerabilities and detection approaches from a defensive perspective.
5. The contents of this repository are provided "AS IS", without any express or implied warranty.
6. If you represent a vendor/security team and need more details, please contact the author via GitHub.

---

Applicability

Technically applicable (prerequisites for each link in the exploit chain to hold)

Link	Prerequisite
Vulnerability itself	Mali kbase driver version falls within the CVE-2021-28664 affected range (r-series before the upstream fix); independent of kernel version, depends only on the driver
GPU resources	/dev/mali reachable by the target application; MEM_ALLOC supports SAME_VA large buffers; MEM_ALIAS behavior matches the vulnerability description
Pipe reuse	Linux ≥ 4.5 (pipe_buf_operations introduced), verified to hold on 4.9 ~ 4.14; F_SETPIPE_SZ can shrink the pipe to a single page
KASLR leak	Kernel has CONFIG_RANDOMIZE_BASE enabled (arm64 ≥ 4.6); anon_pipe_buf_ops exists in the public symbol table
Physical address model	arm64 + vmemmap layout; sizeof(struct page), page table format must be measured empirically, cannot be assumed

Technically not applicable

• Mali drivers that have already fixed CVE-2021-28664 (after the r-version fix);
• Non-Mali GPU platforms (this chain deeply depends on kbase's alias/MMU-dump behavior);
• Newer kernels with significant differences in pipe_buffer structure/copy_page_to_iter validation (from 5.x onward must be re-verified against the corresponding source; the chain structure can be referenced but details are not universal);
• Environments without /dev/mali access (SELinux/vendor policy restrictions).

Boundary statement

• This repository only covers the read/write primitive; locating specific kernel targets after obtaining the primitive, further exploitation, or privilege escalation are all outside the scope of this repository.
• All device-related constants are left blank in the templates as TODO(DEVICE); adaptation is the user's own reverse-engineering work, and the repository does not do it for you.

---

Vulnerability Background

CVE-2021-28664: The MEM_ALIAS path of the Mali kbase driver lacks a check on GPU_WR permission, allowing an attacker to alias already-freed GPU memory pages into their own GPU address space, forming "persistent GPU-side visibility/writability of freed physical pages" — a use-after-free spanning the GPU/kernel boundary.

The exploitation value is not in the GPU memory itself, but in the following:

1. Freed physical pages get reallocated by the kernel slab/buddy to kernel objects (pipe_buffer in this research);
2. The GPU alias view can still see these pages → allowing reading and writing fields of kernel objects in active use;
3. Using GPU WRITE_VALUE jobs to perform targeted overwrites on alias-visible pages.

How Far This Research Goes

victim GPU buffer + MMU page table dump → build physical address map
  → trigger buffer release to create pressure → spray pipes (F_SETPIPE_SZ shrink)
  → pipe_buffer array lands in the freed region (cross-cache UAF reuse)
  → alias view scans ops pointer → leak anon_pipe_buf_ops → KASLR slide
  → GPU overwrites pipe_buffer's page / offset / len
  → via legitimate pipe read/write paths
  ⇒ arbitrary physical page read (forged page pointer)
  ⇒ arbitrary physical page write (pipe merge write path)
  ⇒ use known-content pages as a self-verifying oracle to ensure reads/writes don't land in holes/unmapped regions

That's as far as it goes.

Key Technical Points (each has a dedicated section in docs/)

• Multi-level safety gates: before any physical read, must pass overlap / self-consistency / contiguity / content self-verification and other gates; if any gate fails, immediately restore the scene and exit — the most important engineering discipline of the entire research.
• Pitfalls of the physical address model: GPU PTE software flag bit contamination, physical address 32-bit truncation, KASLR also randomizes the kernel image's physical base address, vendor differences in page_to_virt implementation, no-map reserved regions simply don't exist in the linear mapping (reading them causes a panic).
• Handling m ambiguity: never guess the high bits of physical address ambiguity; use a "known-content page oracle" for content self-verification.
• Primitive lifetime and safe failure: read probes have a count budget; once exceeded, the current round must be abandoned; every exit path of each experiment must restore the tampered object fields.

Repository Structure

docs/
  01-exploit-chain.md            From UAF to read/write primitive: principles and implementation points of each stage
  02-physical-address-model.md   Physical address model, safety gates, m ambiguity, known pitfalls
exploit/
  cve-2021-28664-poc.c           PoC template: complete flow skeleton of the read/write primitive (no device values)
scripts/
  README.md                      Design description of experiment automation tools (loops/verification/recovery)

Source Code Description

exploit/cve-2021-28664-poc.c is the PoC skeleton template for the read/write primitive:

• Retains the complete flow structure (resource preparation → spray → scan → calibration → read/write primitive → restore and exit);
• All device-related constants are marked with TODO(DEVICE), with no directly usable values;
• Every dangerous operation is preceded by explicit verification gates and recovery paths, demonstrating the "safe failure" design approach.

It is used to understand how the entire chain is organized, and cannot be directly compiled into a tool effective against any device.

References

• ARM Mali kbase driver (public kernel source tree)
• CVE-2021-28664 upstream fix records and public analysis
• Linux fs/pipe.c / include/linux/pipe_fs_i.h (public source)
• arm64 memory model: Documentation/arch/arm64/memory.rst (public documentation)

License