Android Mali GPU exploitation

Android Mali GPU exploitation

TL;DR: ARM Mali GPUs are the dominant GPU family in Android devices (Pixel up to certain models, Samsung Exynos, most non-Snapdragon Android). The Mali kernel driver (kbase, MIDGARD/BIFROST/VALHALL architectures) has been a recurring source of kernel LPE bugs reachable from user-mode apps with RENDER group, often without elevated permissions. Heavily targeted at Pwn2Own. Companion to android-components and type-confusion-kernel.

Why Mali matters

  • Reachable from any non-privileged Android app that opens /dev/mali0.
  • Bugs let app context escape to kernel — root, then SELinux bypass.
  • Pwn2Own Mobile pays multipliers for Pixel exploits, and Mali bugs are the typical route.
  • Long-term complex driver, large attack surface: memory management (kbase_mem), job submission, atom-tracking, IOCTL handlers.
  • Affects Pixel 6 / 7 / 8 / 9 (Tensor G1-G4 use Mali variants).

Architecture generations

  • Midgard — Mali-T700/800. Pre-Pixel era.
  • Bifrost — Mali-G31/52/57/76. Common in mid-tier Android.
  • Valhall — Mali-G57/68/77/78/710. Pixel 6/7 (G78/G710), most flagships.
  • Avalon (newer) — successor.

Each generation has its own driver source tree from ARM, but they share the kbase core.

The driver attack surface

Userland opens /dev/mali0 and issues IOCTLs:

  • KBASE_FUNC_MEM_ALLOC — allocate GPU-visible memory.
  • KBASE_FUNC_MEM_QUERY / KBASE_FUNC_MEM_FLAGS_CHANGE — manipulate.
  • KBASE_FUNC_JOB_SUBMIT — submit GPU job (atom).
  • KBASE_FUNC_KCPU_QUEUE_* — KCPU (kernel-CPU job) queue ops.
  • KBASE_FUNC_SOFT_EVENT_* — synchronisation primitives.

Each handler is a candidate sink for memory-corruption or logic bugs.

Common bug classes

Use-after-free in atom / KCPU queue

A “GPU atom” (job) is queued and freed asynchronously. UAF arises when:

  • Atom freed during dependency resolution but referenced later.
  • Race between job-cancel and job-execute.

Type confusion across job slots

Multiple job slots; struct casting between slots when slot-id is wrong.

Out-of-bounds memory mapping

KBASE_FUNC_MEM_ALLOC parameters allow attacker to influence sizes / offsets. Bugs:

  • Size check off-by-one.
  • Integer overflow in size * count calculation.
  • Mapping flags allow writable+executable in shared memory.

Page-table corruption

The driver maintains GPU page tables. Bugs allow modifying entries the user app shouldn’t be able to:

  • Map kernel pages into GPU address space → GPU sees kernel memory.
  • Map physical pages into other process’s GPU AS.

Stale handle references

GPU buffer handles tracked in a table. Closing a handle then reopening another may return the same index; if handler doesn’t validate, attacker uses a stale reference.

CVE patterns (selection)

  • CVE-2022-46395, CVE-2023-26083 — historical Mali bugs.
  • CVE-2023-4211 (in-the-wild exploitation reported).
  • CVE-2024-XXXXX — ongoing flow of Mali kernel bugs disclosed via Pwn2Own and through Project Zero.

The pattern is consistent: a new generation of the driver gets shipped; bugs are found within weeks. ARM’s typical fix lag is months until the patch reaches Pixel’s monthly bulletin.

Pixel-specific considerations

  • Pixel 6+ uses Google’s Tensor SoC with ARM-licensed Mali.
  • Google ships monthly security bulletin patches for the Mali driver.
  • Patch lag from upstream ARM advisory to Pixel deployment is sometimes weeks.
  • Other Android OEMs (Samsung, Xiaomi) ship patches less reliably; older devices receive nothing.

Workflow to study (lab only)

  1. Acquire a developer Pixel (e.g., Pixel 6 with unlockable bootloader).
  2. Install AOSP build with debug symbols.
  3. Use mali_kbase driver source from kernel tree to identify IOCTL handlers.
  4. Reproduce a public CVE PoC (post-patch, you can run on a non-patched legacy ROM).
  5. Use ftrace / KASAN to validate the bug.
  6. Examine the patch.

Do not test on a phone you rely on; flashing custom ROMs voids warranties and wipes data.

Tooling

  • adb and root for development.
  • Frida for runtime introspection.
  • ghidra for driver static analysis.
  • Public exploits and PoCs on GitHub (vetted accounts).
  • KASAN-enabled debug kernels for crash diagnosis.

EDR / Android equivalent visibility

For Android there’s no EDR in the desktop sense. Mali bugs evade most detection because they execute in kernel context without crossing user-visible IPC.

Detection approaches:

  • Crash reporting (Google Play Protect’s anomalous-crash detection).
  • Behavioural anomalies in kbase kernel calls (research-grade, not deployed).

Defensive baseline

  • Pixel: apply monthly security patches immediately.
  • Other OEMs: choose vendors with sustained patch commitment (Samsung Galaxy S/Note flagships).
  • Avoid sideloading apps from unknown sources — though many Mali exploits are reachable from any installed app.
  • Watch Project Zero / TAG (Threat Analysis Group) reports for in-the-wild Mali exploitation.

References