From: Carlos Llamas <cmllamas@google.com>
To: "Greg Kroah-Hartman" <gregkh@linuxfoundation.org>,
"Arve Hjønnevåg" <arve@android.com>,
"Todd Kjos" <tkjos@android.com>,
"Martijn Coenen" <maco@android.com>,
"Joel Fernandes" <joel@joelfernandes.org>,
"Christian Brauner" <brauner@kernel.org>,
"Carlos Llamas" <cmllamas@google.com>,
"Suren Baghdasaryan" <surenb@google.com>,
"Yu-Ting Tseng" <yutingtseng@google.com>
Cc: linux-kernel@vger.kernel.org, kernel-team@android.com,
Alice Ryhl <aliceryhl@google.com>,
stable@vger.kernel.org
Subject: [PATCH 2/4] binder: fix OOB in binder_add_freeze_work()
Date: Tue, 24 Sep 2024 18:43:54 +0000 [thread overview]
Message-ID: <20240924184401.76043-3-cmllamas@google.com> (raw)
In-Reply-To: <20240924184401.76043-1-cmllamas@google.com>
In binder_add_freeze_work() we iterate over the proc->nodes with the
proc->inner_lock held. However, this lock is temporarily dropped to
acquire the node->lock first (lock nesting order). This can race with
binder_deferred_release() which removes the nodes from the proc->nodes
rbtree and adds them into binder_dead_nodes list. This leads to a broken
iteration in binder_add_freeze_work() as rb_next() will use data from
binder_dead_nodes, triggering an out-of-bounds access:
==================================================================
BUG: KASAN: global-out-of-bounds in rb_next+0xfc/0x124
Read of size 8 at addr ffffcb84285f7170 by task freeze/660
CPU: 8 UID: 0 PID: 660 Comm: freeze Not tainted 6.11.0-07343-ga727812a8d45 #18
Hardware name: linux,dummy-virt (DT)
Call trace:
rb_next+0xfc/0x124
binder_add_freeze_work+0x344/0x534
binder_ioctl+0x1e70/0x25ac
__arm64_sys_ioctl+0x124/0x190
The buggy address belongs to the variable:
binder_dead_nodes+0x10/0x40
[...]
==================================================================
This is possible because proc->nodes (rbtree) and binder_dead_nodes
(list) share entries in binder_node through a union:
struct binder_node {
[...]
union {
struct rb_node rb_node;
struct hlist_node dead_node;
};
Fix the race by checking that the proc is still alive. If not, simply
break out of the iteration.
Fixes: d579b04a52a1 ("binder: frozen notification")
Cc: stable@vger.kernel.org
Signed-off-by: Carlos Llamas <cmllamas@google.com>
---
drivers/android/binder.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/android/binder.c b/drivers/android/binder.c
index 4d90203ea048..8bca2de6fa24 100644
--- a/drivers/android/binder.c
+++ b/drivers/android/binder.c
@@ -5593,6 +5593,8 @@ static void binder_add_freeze_work(struct binder_proc *proc, bool is_frozen)
prev = node;
binder_node_unlock(node);
binder_inner_proc_lock(proc);
+ if (proc->is_dead)
+ break;
}
binder_inner_proc_unlock(proc);
if (prev)
--
2.46.0.792.g87dc391469-goog
next prev parent reply other threads:[~2024-09-24 18:44 UTC|newest]
Thread overview: 21+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-09-24 18:43 [PATCH 0/4] binder: several fixes for frozen notification Carlos Llamas
2024-09-24 18:43 ` [PATCH 1/4] binder: fix node UAF in binder_add_freeze_work() Carlos Llamas
2024-09-25 2:58 ` Todd Kjos
2024-09-25 8:03 ` Alice Ryhl
2024-09-24 18:43 ` Carlos Llamas [this message]
2024-09-25 3:03 ` [PATCH 2/4] binder: fix OOB " Todd Kjos
2024-09-25 8:02 ` Alice Ryhl
2024-09-25 17:48 ` Carlos Llamas
2024-09-25 17:52 ` Alice Ryhl
2024-09-25 18:06 ` Carlos Llamas
2024-09-25 18:09 ` Carlos Llamas
2024-09-26 8:06 ` Alice Ryhl
2024-09-26 14:39 ` Carlos Llamas
2024-09-24 18:43 ` [PATCH 3/4] binder: fix freeze UAF in binder_release_work() Carlos Llamas
2024-09-25 0:52 ` Todd Kjos
2024-09-25 8:03 ` Alice Ryhl
2024-09-24 18:43 ` [PATCH 4/4] binder: fix BINDER_WORK_FROZEN_BINDER debug logs Carlos Llamas
2024-09-25 0:43 ` Todd Kjos
2024-09-25 7:36 ` Alice Ryhl
2024-09-25 17:25 ` Carlos Llamas
2024-09-26 3:54 ` Carlos Llamas
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20240924184401.76043-3-cmllamas@google.com \
--to=cmllamas@google.com \
--cc=aliceryhl@google.com \
--cc=arve@android.com \
--cc=brauner@kernel.org \
--cc=gregkh@linuxfoundation.org \
--cc=joel@joelfernandes.org \
--cc=kernel-team@android.com \
--cc=linux-kernel@vger.kernel.org \
--cc=maco@android.com \
--cc=stable@vger.kernel.org \
--cc=surenb@google.com \
--cc=tkjos@android.com \
--cc=yutingtseng@google.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox