Exploit-DB #46356
Description: Android - binder Use-After-Free via fdget() Optimization
Type: dos
Platform: android
Date: 2019-02-12
Author: Google Security Research

Exploit:
This bug report describes *two* different issues in different branches of the
binder kernel code.
The first issue is in the upstream Linux kernel,
commit 7f3dc0088b98 ("binder: fix proc->files use-after-free");
the second issue is in the wahoo kernel (and maybe elsewhere? but at least the
android common kernel for 4.4 doesn't seem to contain this code...),
commit 1b652c7c29b7 ("FROMLIST: binder: fix proc->files use-after-free")
(WARNING: NOT the same as "UPSTREAM: binder: fix proc->files use-after-free" in
the android common kernel!).

Some background: In the Linux kernel, normally, when a `struct file *` is read
from the file descriptor table, the reference counter of the `struct file` is
bumped to account for the extra reference; this happens in fget(). Later, if the
extra reference is not needed anymore, the refcount is dropped via fput().
A negative effect of this is that, if the `struct file` is frequently accessed,
the cacheline containing the reference count is constantly dirty; and if the
`struct file` is used by multiple tasks in parallel, cache line bouncing occurs.

Linux provides the helpers fdget() and fdput() to avoid this overhead.
fdget() checks whether the reference count of the file descriptor table is 1,
implying that the current task has sole ownership of the file descriptor table
and no concurrent modifications of the file descriptor table can occur. If this
check succeeds, fdget() then omits the reference count increment on the
`struct file`. fdget() sets a flag in its return value that signals to fdput()
whether a reference count has been taken. If so, fdput() uses the normal fput()
logic; if not, fdput() does nothing.

This optimization relies on a few rules, including:

A) A reference taken via fdget() must be dropped with fdput() before the end of
   the syscall.
B) A task's reference to its file descriptor table may only be duplicated for
   writing if that task is known to not be between fdget() and fdput().
C) A task that might be between an elided fdget() and fdput() must not
   use ksys_close() on the same file descriptor number as used for fdget().



The current upstream code violates rule C. The following sequence of events can
cause fput() to drop the reference count of an in-use binder file to drop to
zero:

Task A and task B are connected via binder; task A has /dev/binder open at
file descriptor number X. Both tasks are single-threaded.

 - task B sends a binder message with a file descriptor array (BINDER_TYPE_FDA)
   containing one file descriptor to task A
 - task A reads the binder message with the translated file descriptor number Y
 - task A uses dup2(X, Y) to overwrite file descriptor Y with the /dev/binder
   file
 - task A unmaps the userspace binder memory mapping; the reference count on
   task A's /dev/binder is now 2
 - task A closes file descriptor X; the reference count on task A's /dev/binder
   is now 1
 - task A invokes the BC_FREE_BUFFER command on file descriptor X to release the
   incoming binder message
 - fdget() elides the reference count increment, since the file descriptor
   table is not shared
 - the BC_FREE_BUFFER handler removes the file descriptor table entry for X and
   decrements the reference count of task A's /dev/binder file to zero

Because fput() uses the task work mechanism to actually free the file, this
doesn't immediately cause a use-after-free that KASAN can detect; for that, the
following sequence of events works:

[...]
 - task A closes file descriptor X; the reference count on task A's /dev/binder
   is now 1
 - task A forks off a child, task C, duplicating the file descriptor table; the
   reference count on task A's /dev/binder is now 2
 - task A invokes the BC_FREE_BUFFER command on file descriptor X to release the
   incoming binder message
 - fdget() in ksys_ioctl() elides the reference count increment, since the file
   descriptor table is not shared
 - the BC_FREE_BUFFER handler removes the file descriptor table entry for X and
   decrements the reference count of task A's /dev/binder file to 1
 - task C calls close(X), which drops the reference count of task A's
   /dev/binder to 0 and frees it
 - task A continues processing of the ioctl and accesses some property of e.g.
   the binder_proc => KASAN-detectable UAF

To reproduce this on an upstream git master kernel on a normal machine, unpack
the attached binder_fdget.tar, apply the patch
0001-binder-upstream-repro-aid.patch to the kernel (adds some logging and an
msleep() call), make sure that the kernel is configured with Binder and KASAN,
build and boot into the kernel, then build the PoC with ./compile.sh.
Invoke "./exploit_manager" in one terminal and "./exploit_client" in another
terminal. You should see a splat like this in dmesg:

=================
[   90.900693] BUG: KASAN: use-after-free in mutex_lock+0x77/0xd0
[   90.903933] Write of size 8 at addr ffff8881da262720 by task exploit_client/1222

[   90.908991] CPU: 4 PID: 1222 Comm: exploit_client Tainted: G        W         4.20.0-rc3+ #214
[   90.911524] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.10.2-1 04/01/2014
[   90.913989] Call Trace:
[   90.914768]  dump_stack+0x71/0xab
[   90.915782]  print_address_description+0x6a/0x270
[   90.917199]  kasan_report+0x260/0x380
[   90.918307]  ? mutex_lock+0x77/0xd0
[   90.919387]  mutex_lock+0x77/0xd0
[...]
[   90.925971]  binder_alloc_prepare_to_free+0x22/0x130
[   90.927429]  binder_thread_write+0x7c1/0x1b20
[...]
[   90.944008]  binder_ioctl+0x916/0xe80
[...]
[   90.955530]  do_vfs_ioctl+0x134/0x8f0
[...]
[   90.961135]  ksys_ioctl+0x70/0x80
[   90.962070]  __x64_sys_ioctl+0x3d/0x50
[   90.963125]  do_syscall_64+0x73/0x160
[   90.964162]  entry_SYSCALL_64_after_hwframe+0x44/0xa9
[...]

[   90.984647] Allocated by task 1222:
[   90.985614]  kasan_kmalloc+0xa0/0xd0
[   90.986602]  kmem_cache_alloc_trace+0x6e