Re: [tip:core/urgent] futex: Fix more put_pi_state() vs. exit_pi_state_list() races

From: Thomas Gleixner
Date: Tue Oct 31 2017 - 18:11:48 EST


On Tue, 31 Oct 2017, tip-bot for Peter Zijlstra wrote:
> Commit-ID: d5f6ac33189af48a0dc011190af5144947a30a76
> Gitweb: https://git.kernel.org/tip/d5f6ac33189af48a0dc011190af5144947a30a76
> Author: Peter Zijlstra <peterz@xxxxxxxxxxxxx>
> AuthorDate: Tue, 31 Oct 2017 11:18:53 +0100
> Committer: Ingo Molnar <mingo@xxxxxxxxxx>
> CommitDate: Tue, 31 Oct 2017 11:54:52 +0100
>
> futex: Fix more put_pi_state() vs. exit_pi_state_list() races
>
> 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@xxxxxxxxxx>
> Signed-off-by: Peter Zijlstra (Intel) <peterz@xxxxxxxxxxxxx>
> Cc: Gratian Crisan <gratian.crisan@xxxxxx>
> Cc: Linus Torvalds <torvalds@xxxxxxxxxxxxxxxxxxxx>
> Cc: Peter Zijlstra <peterz@xxxxxxxxxxxxx>
> Cc: Thomas Gleixner <tglx@xxxxxxxxxxxxx>
> Cc: dvhart@xxxxxxxxxxxxx
> Cc: syzbot <bot+2af19c9e1ffe4d4ee1d16c56ae7580feaee75765@xxxxxxxxxxxxxxxxxxxxxxxxx>
> Cc: syzkaller-bugs@xxxxxxxxxxxxxxxx
> Fixes: c74aef2d06a9 ("futex: Fix pi_state->owner serialization")
> Link: http://lkml.kernel.org/r/20171031101853.xpfh72y643kdfhjs@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
> Signed-off-by: Ingo Molnar <mingo@xxxxxxxxxx>

That lacks a stable tag.

Other than that a late:

Reviewed-by: Thomas Gleixner <tglx@xxxxxxxxxxxxx>