ExplosION: The Hidden Mines in the Android ION Driver

## Overview

In the presentation *"ExplosION: The Hidden Mines in the Android ION Driver,"* security researchers Le Wu, Xuen Li, and Tim Xia from Baidu Security present their discovery of over 40 vulnerabilities in Android's ION memory management subsystem, a series of flaws collectively termed **ExplosION**.

Google originally introduced ION as a generalized memory pool manager to unify and resolve fragmented memory management interfaces across Android devices. Before ION, disparate drivers handled distinct allocation tasks—such as allocating physically contiguous buffers versus non-contiguous buffers. ION consolidated these requirements by introducing configurable memory pools known as **ION heaps** (such as the system heap based on `vmalloc`), while allowing hardware vendors to implement custom heaps for specialized hardware needs.

## Why Target the Android ION Driver?

The research team focused on ION due to several key systemic factors: - **Broad Attack Surface:** As a common Android driver, vulnerabilities within ION impact millions of devices across vendors. - **Untrusted App Accessibility:** The ION device interface is directly accessible by untrusted user applications, making it an attractive target for local privilege escalation similar to the Android Binder driver. - **Criticality of Memory Managers:** Memory management flaws have historically led to severe kernel exploitation (e.g., Dirty COW). - **Turbulent Refactoring History:** Upstream ION underwent substantial refactoring cycles—first introduced around 2012 ("Legacy ION"), refactored in 2017, refactored again in 2019, and eventually replaced by `dma-buf` heaps starting in Android 12 (2021). Despite this phase-out, Android ecosystem fragmentation ensures ION remains widely deployed across millions of legacy devices.

## ION Architecture and Memory Operations

The speakers analyzed the foundational design of Legacy ION to illustrate how operations are exposed between user space and kernel space:

- **Buffer Allocation:** A user space process opens the ION device to obtain a client file descriptor (`client fd`). Invoking the `ION_IOC_ALLOC` `ioctl` command prompts ION to create an `ion_handle` object associated with an underlying `ion_buffer` representing the allocated memory. The handle ID is returned to user space for further operations. - **Buffer Deallocation:** Applications release memory buffers by passing the handle ID back via the `ION_IOC_FREE` command, triggering the release of associated kernel objects and physical memory. - **Buffer Sharing via DMA-BUF:** User processes request buffer sharing via `ION_IOC_SHARE`. ION binds a `dma-buf` object to the `ion_buffer` and exports its file descriptor (`fd`) to user space. Processes can map this file descriptor to access shared memory across user space and kernel space simultaneously. - **Kernel-Level Interfaces:** In addition to user space `ioctl` entry points, ION functions as a foundational driver offering internal kernel APIs (such as `ion_alloc`, `ion_free`, and `ion_map_kernel`) utilized directly by other kernel drivers.

## Research Findings & Significance

By auditing the core design and vendor implementations of ION, the researchers uncovered more than 40 vulnerabilities ("ExplosION"). The extensive refactoring and eventual deprecation of the subsystem reflected chronic architectural and implementation security challenges that lingered across vendor kernels, leaving millions of active Android devices vulnerable to exploitation.