From: Ben Hutchings <ben@decadent.org.uk>
To: stable@vger.kernel.org
Cc: Lee Jones <lee.jones@linaro.org>,
"Luis Claudio R. Goncalves" <lgoncalv@redhat.com>
Subject: [PATCH 4.9 6/7] futex: Fix more put_pi_state() vs. exit_pi_state_list() races
Date: Mon, 1 Mar 2021 18:31:55 +0100 [thread overview]
Message-ID: <YD0lC+fuTMO3BKSw@decadent.org.uk> (raw)
In-Reply-To: <YD0kv9H996Tkhg2o@decadent.org.uk>
[-- Attachment #1: Type: text/plain, Size: 3598 bytes --]
From: Peter Zijlstra <peterz@infradead.org>
commit 153fbd1226fb30b8630802aa5047b8af5ef53c9f upstream.
Dmitry (through syzbot) reported being able to trigger the WARN in
get_pi_state() and a use-after-free on:
raw_spin_lock_irq(&pi_state->pi_mutex.wait_lock);
Both are due to this race:
exit_pi_state_list() put_pi_state()
lock(&curr->pi_lock)
while() {
pi_state = list_first_entry(head);
hb = hash_futex(&pi_state->key);
unlock(&curr->pi_lock);
dec_and_test(&pi_state->refcount);
lock(&hb->lock)
lock(&pi_state->pi_mutex.wait_lock) // uaf if pi_state free'd
lock(&curr->pi_lock);
....
unlock(&curr->pi_lock);
get_pi_state(); // WARN; refcount==0
The problem is we take the reference count too late, and don't allow it
being 0. Fix it by using inc_not_zero() and simply retrying the loop
when we fail to get a refcount. In that case put_pi_state() should
remove the entry from the list.
Reported-by: Dmitry Vyukov <dvyukov@google.com>
Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
Reviewed-by: Thomas Gleixner <tglx@linutronix.de>
Cc: Gratian Crisan <gratian.crisan@ni.com>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: dvhart@infradead.org
Cc: syzbot <bot+2af19c9e1ffe4d4ee1d16c56ae7580feaee75765@syzkaller.appspotmail.com>
Cc: syzkaller-bugs@googlegroups.com
Cc: <stable@vger.kernel.org>
Fixes: c74aef2d06a9 ("futex: Fix pi_state->owner serialization")
Link: http://lkml.kernel.org/r/20171031101853.xpfh72y643kdfhjs@hirez.programming.kicks-ass.net
Signed-off-by: Ingo Molnar <mingo@kernel.org>
Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
---
kernel/futex.c | 23 ++++++++++++++++++++---
1 file changed, 20 insertions(+), 3 deletions(-)
diff --git a/kernel/futex.c b/kernel/futex.c
index a07f6080c8b0..855dae277f83 100644
--- a/kernel/futex.c
+++ b/kernel/futex.c
@@ -941,11 +941,27 @@ static void exit_pi_state_list(struct task_struct *curr)
*/
raw_spin_lock_irq(&curr->pi_lock);
while (!list_empty(head)) {
-
next = head->next;
pi_state = list_entry(next, struct futex_pi_state, list);
key = pi_state->key;
hb = hash_futex(&key);
+
+ /*
+ * We can race against put_pi_state() removing itself from the
+ * list (a waiter going away). put_pi_state() will first
+ * decrement the reference count and then modify the list, so
+ * its possible to see the list entry but fail this reference
+ * acquire.
+ *
+ * In that case; drop the locks to let put_pi_state() make
+ * progress and retry the loop.
+ */
+ if (!atomic_inc_not_zero(&pi_state->refcount)) {
+ raw_spin_unlock_irq(&curr->pi_lock);
+ cpu_relax();
+ raw_spin_lock_irq(&curr->pi_lock);
+ continue;
+ }
raw_spin_unlock_irq(&curr->pi_lock);
spin_lock(&hb->lock);
@@ -956,8 +972,10 @@ static void exit_pi_state_list(struct task_struct *curr)
* task still owns the PI-state:
*/
if (head->next != next) {
+ /* retain curr->pi_lock for the loop invariant */
raw_spin_unlock(&pi_state->pi_mutex.wait_lock);
spin_unlock(&hb->lock);
+ put_pi_state(pi_state);
continue;
}
@@ -965,9 +983,8 @@ static void exit_pi_state_list(struct task_struct *curr)
WARN_ON(list_empty(&pi_state->list));
list_del_init(&pi_state->list);
pi_state->owner = NULL;
- raw_spin_unlock(&curr->pi_lock);
- get_pi_state(pi_state);
+ raw_spin_unlock(&curr->pi_lock);
raw_spin_unlock_irq(&pi_state->pi_mutex.wait_lock);
spin_unlock(&hb->lock);
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
next prev parent reply other threads:[~2021-03-01 17:41 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-03-01 17:30 [PATCH 4.9 1/7] futex: Cleanup variable names for futex_top_waiter() Ben Hutchings
2021-03-01 17:31 ` [PATCH 4.9 2/7] futex: Cleanup refcounting Ben Hutchings
2021-03-01 17:31 ` [PATCH 4.9 3/7] futex: Pull rt_mutex_futex_unlock() out from under hb->lock Ben Hutchings
2021-03-01 17:31 ` [PATCH 4.9 4/7] futex: Futex_unlock_pi() determinism Ben Hutchings
2021-03-01 17:31 ` [PATCH 4.9 5/7] futex: Fix pi_state->owner serialization Ben Hutchings
2021-03-01 17:31 ` Ben Hutchings [this message]
2021-03-01 17:32 ` [PATCH 4.9 7/7] futex: Don't enable IRQs unconditionally in put_pi_state() Ben Hutchings
2021-03-04 13:11 ` [PATCH 4.9 1/7] futex: Cleanup variable names for futex_top_waiter() Greg KH
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=YD0lC+fuTMO3BKSw@decadent.org.uk \
--to=ben@decadent.org.uk \
--cc=lee.jones@linaro.org \
--cc=lgoncalv@redhat.com \
--cc=stable@vger.kernel.org \
/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