linux-kernel - Re: [4.1 backport trouble] Re: BUGreport: fix minor infoleak in get_user

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] [day] [month] [year] [list]

Message-ID: <20161028212947.GA25964@kroah.com>
Date:   Fri, 28 Oct 2016 17:29:47 -0400
From:   Greg KH <greg@...ah.com>
To:     Al Viro <viro@...IV.linux.org.uk>
Cc:     Linus Torvalds <torvalds@...ux-foundation.org>,
        Joe Korty <joe.korty@...r.com>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
        Sasha Levin <alexander.levin@...izon.com>,
        stable <stable@...r.kernel.org>
Subject: Re: [4.1 backport trouble] Re: BUGreport: fix minor infoleak in
 get_user_ex()

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