binder: fix UAF when releasing todo list
authorTodd Kjos <tkjos@google.com>
Tue, 21 Jul 2020 04:14:33 +0000 (21:14 -0700)
committerPDO SCM Team <hudsoncm@motorola.com>
Sun, 4 Oct 2020 07:00:35 +0000 (02:00 -0500)
commit0ec7edbd6e06612be08a849b6a75dc2e27211eb9
tree2d4647972d95512518a7942edeae386c0200c388
parent8105ce8de6ba692bbce654f4a2d2daf99ef88d51
binder: fix UAF when releasing todo list

When releasing a thread todo list when tearing down
a binder_proc, the following race was possible which
could result in a use-after-free:

1.  Thread 1: enter binder_release_work from binder_thread_release
2.  Thread 2: binder_update_ref_for_handle() calls binder_dec_node_ilocked()
3.  Thread 2: dec nodeA --> 0 (will free node)
4.  Thread 1: ACQ inner_proc_lock
5.  Thread 2: block on inner_proc_lock
6.  Thread 1: dequeue work (BINDER_WORK_NODE, part of nodeA)
7.  Thread 1: REL inner_proc_lock
8.  Thread 2: ACQ inner_proc_lock
9.  Thread 2: todo list cleanup, but work was already dequeued
10. Thread 2: free node
11. Thread 2: REL inner_proc_lock
12. Thread 1: deref w->type (UAF)

The problem was that for a BINDER_WORK_NODE, the binder_work element
must not be accessed after releasing the inner_proc_lock while
processing the todo list elements since another thread might be
handling a deref on the node containing the binder_work element
leading to the node being freed.

Mot-CRs-fixed: (CR)
CVE-Fixed: CVE-2020-0423
Bug: 161151868

Signed-off-by: Todd Kjos <tkjos@google.com>
Change-Id: I4ae752abfe1aa38872be6f266ddd271802952625
Signed-off-by: Jignesh Patel <jignesh@motorola.com>
Reviewed-on: https://gerrit.mot.com/1747882
SLTApproved: Slta Waiver
SME-Granted: SME Approvals Granted
Tested-by: Jira Key
Reviewed-by: Xiangpo Zhao <zhaoxp3@motorola.com>
Submit-Approved: Jira Key
(cherry picked from commit dd0333429049cf16ce07df311dfcd5495416f12d)
drivers/android/binder.c