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 -- To unsubscribe from this list: send the line "unsubscribe stable" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html