linux-kernel - Re: [PATCH] futex: Fix potential use-after-free in FUTEX_REQUEUE

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20161201053427.GD3092@twins.programming.kicks-ass.net>
Date:   Thu, 1 Dec 2016 06:34:27 +0100
From:   Peter Zijlstra <peterz@...radead.org>
To:     Darren Hart <dvhart@...radead.org>
Cc:     Thomas Gleixner <tglx@...utronix.de>,
        Ingo Molnar <mingo@...nel.org>, linux-kernel@...r.kernel.org
Subject: Re: [PATCH] futex: Fix potential use-after-free in FUTEX_REQUEUE_PI

On Wed, Nov 30, 2016 at 08:55:30PM -0800, Darren Hart wrote:
> On Thu, Nov 24, 2016 at 04:38:08PM +0100, Peter Zijlstra wrote:

> > > In this path the fixup can return -EFAIL as well, so it should drop rtmutex
> > > too if it owns it. We should move the rtmutex drop into the fixup functions...
> > 
> > Urgh, so would really like to avoid doing that, I'll have to instantly
> > drag it back out again :/
> 
> Why would you have to drag it back out again? Something else you're working on?

Yeah, the very reason I've been staring at this mess in the first place
:-)

So I could point you at the patches; and I will, see:

  https://lkml.kernel.org/r/20161021122735.GA3117@twins.programming.kicks-ass.net

but the TL;DR version is that we must not rt_mutex_unlock() while
holding hb->lock, because on RT hb->lock is itself a rt_mutex which
gives rise to some very fun prio inversions.