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 for Android: free password hash cracker in your pocket
[<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

Powered by Openwall GNU/*/Linux Powered by OpenVZ