[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20161028194958.GP19539@ZenIV.linux.org.uk>
Date: Fri, 28 Oct 2016 20:49:58 +0100
From: Al Viro <viro@...IV.linux.org.uk>
To: Linus Torvalds <torvalds@...ux-foundation.org>
Cc: 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 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.
Powered by blists - more mailing lists