binder: fix UAF when releasing todo list
authorTodd Kjos <tkjos@google.com>
Tue, 21 Jul 2020 04:14:33 +0000 (21:14 -0700)
committerchenyt17 <chenyt17@lenovo.com>
Fri, 28 May 2021 07:07:54 +0000 (15:07 +0800)
commit97e57c2f217e8ca8d74fa7d362cf8a1e303b6e30
tree67eba598ed67b23d4dead32e3f16e459f7b49e27
parent53c8a7fb41c6dd7c08aba467c674d773519750cb
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