From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <stable-owner@vger.kernel.org>
Received: from out5-smtp.messagingengine.com ([66.111.4.29]:49246 "EHLO
        out5-smtp.messagingengine.com" rhost-flags-OK-OK-OK-OK)
        by vger.kernel.org with ESMTP id S933956AbcJ1V3i (ORCPT
        <rfc822;stable@vger.kernel.org>); Fri, 28 Oct 2016 17:29:38 -0400
Date: Fri, 28 Oct 2016 17:29:47 -0400
From: Greg KH <greg@kroah.com>
To: Al Viro <viro@ZenIV.linux.org.uk>
Cc: Linus Torvalds <torvalds@linux-foundation.org>,
        Joe Korty <joe.korty@ccur.com>,
        Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
        Sasha Levin <alexander.levin@verizon.com>,
        stable <stable@vger.kernel.org>
Subject: Re: [4.1 backport trouble] Re: BUGreport: fix minor infoleak in
 get_user_ex()
Message-ID: <20161028212947.GA25964@kroah.com>
References: <20161027193210.GA23006@zipoli.ccur.com>
 <20161028000355.GK19539@ZenIV.linux.org.uk>
 <20161028020210.GL19539@ZenIV.linux.org.uk>
 <20161028164033.GA29952@zipoli.ccur.com>
 <CA+55aFy=k-3LEJStj=nrujefJp3BEcJBG3yESS5=SemWTQ5hnA@mail.gmail.com>
 <20161028194958.GP19539@ZenIV.linux.org.uk>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20161028194958.GP19539@ZenIV.linux.org.uk>
Sender: stable-owner@vger.kernel.org
List-ID: <stable.vger.kernel.org>

On Fri, Oct 28, 2016 at 08:49:58PM +0100, Al Viro wrote:
> On Fri, Oct 28, 2016 at 11:21:24AM -0700, Linus Torvalds wrote:
> 
> > End result: either commit 1c109fabbd51 shouldn't be backported (it's
> > really not that important - if people properly check the exception
> > error results it shouldn't matter), or you need to also backport
> > 548acf19234d as Al suggested.
> > 
> > I'd be inclined to say "don't backport 1c109fabbd51", but it's really
> > a judgment call.
> 
> *nod*
> 
> FWIW, that infoleak _does_ allow to leak an uninitialized word into
> coredump (in sigreturn the value from uninitialized local variable is
> copied into pt_regs of process and when we eventually check that error
> has happened and hit the sucker with SIGSEGV, that value gets stored into
> the coredump), but in the worst case that's 64 bits leaked from fixed depth
> in the kernel stack of attacker's process, with fixed call chain.
> 
> I very much doubt that it's escalatable to anything practically interesting.
> If spender et.al. can come up with a usable way to escalate that, I would be
> quite surprised (and would love to see the details), but hey, it might be
> possible.  More likely possibility is that the bug is harmless in practice.

Hm, I think I'll backport 548acf19234d to 4.4-stable, as people have
shown that leaking anything can be used in odd ways that they shouldn't
be, just to be "safe" :)

thanks for the heads up.

greg k-h