Re: [4.1 backport trouble] Re: BUGreport: fix minor infoleak in get_user_ex()

[Greg KH <greg@kroah.com>]

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