summaryrefslogtreecommitdiff
path: root/drivers/base
diff options
context:
space:
mode:
authorTodd Kjos <tkjos@google.com>2020-10-09 16:24:55 -0700
committerTodd Kjos <tkjos@google.com>2020-10-20 14:17:19 -0700
commit7a9986e91f90994623e4c5de1effce14729dba96 (patch)
treededb47d2b7212c25290dfd923435f1a2426daef3 /drivers/base
parent887cae0a5083d67ca72016144a8e72258f41877c (diff)
UPSTREAM: 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() -> 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. Signed-off-by: Todd Kjos <tkjos@google.com> Link: https://lore.kernel.org/r/20201009232455.4054810-1-tkjos@google.com Cc: <stable@vger.kernel.org> # 4.14, 4.19, 5.4, 5.8 Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> (cherry picked from commit f3277cbfba763cd2826396521b9296de67cf1bbc) Change-Id: I7c1bf0b74824f272664e76206c5dc3b66b9eeaff Signed-off-by: Greg Kroah-Hartman <gregkh@google.com>
Diffstat (limited to 'drivers/base')
0 files changed, 0 insertions, 0 deletions