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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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.
--
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



[Index of Archives]     [Linux Kernel]     [Kernel Development Newbies]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Yosemite Hiking]     [Linux Kernel]     [Linux SCSI]