summaryrefslogtreecommitdiffstats
path: root/drivers/pci/search.c
diff options
context:
space:
mode:
authorTodd Kjos <tkjos@google.com>2020-10-09 16:24:55 -0700
committerGreg Kroah-Hartman <gregkh@linuxfoundation.org>2020-10-10 12:40:52 +0200
commitf3277cbfba763cd2826396521b9296de67cf1bbc (patch)
tree0c01472c66441c27ea1389578e25a2ee8ce2a9f6 /drivers/pci/search.c
parent78eef5d952610b8a9c94cfee19ab83b64135e189 (diff)
downloadlinux-f3277cbfba763cd2826396521b9296de67cf1bbc.tar.bz2
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>
Diffstat (limited to 'drivers/pci/search.c')
0 files changed, 0 insertions, 0 deletions