binder: fix UAF when releasing todo list android-10-release-qsas MMI-QSAS30.62-24-14 MMI-QSAS30.62-24-26-14
authorTodd Kjos <tkjos@google.com>
Tue, 21 Jul 2020 04:14:33 +0000 (21:14 -0700)
committerchenyt17 <chenyt17@lenovo.com>
Fri, 17 Jun 2022 03:28:34 +0000 (11:28 +0800)
commit4b05bd5ca8c161d6909d84d1f7fe2deedc82a60f
treec2154b37a9776d3c8bb0705fe92ab99271d7bb4e
parent94c45b93038f700953a0341671371c1c5c38193b
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