oss-sec mailing list archives

Re: Linux kernel futex local privilege escalation (CVE-2014-3153)


From: Greg KH <greg () kroah com>
Date: Fri, 6 Jun 2014 08:21:20 -0700

On Fri, Jun 06, 2014 at 04:24:23PM +0200, rf () q-leap de wrote:
"Greg" == Greg KH <greg () kroah com> writes:

    Greg> On Fri, Jun 06, 2014 at 11:11:42AM +0200, rf () q-leap de wrote:
    >> >>>>> "Thomas" == Thomas Gleixner <tglx () linutronix de> writes:
    >>
    >> Hi Thomas,
    >>
    >> >> On Thu, Jun 05, 2014 at 11:38:27PM -0400, Rich Felker wrote:
    >> >> > On Thu, Jun 05, 2014 at 06:45:45PM +0400, Solar Designer
    >> >> > wrote:
    >> >> > > I've attached patches by Thomas Gleixner (four e-mails, in
    >> >> > > mbox format), as well as back-ports of those by John
    >> >> > > Johansen of Canonical, who wrote:
    >> >> >
    >> >> > Maybe I'm missing something, but I can't find any statement
    >> >> > of what version these patches are intended to apply cleanly
    >> >> > to. They don't apply to latest stable.
    >> >>
    >> >> Thomas - can you answer Rich's question?  This is about
    >> >> patches you sent on June 3 to linux-distros, which Kees then
    >> >> saved into an mbox file.
    >>
    Thomas> They should apply cleanly, if all stable tagged futex
    Thomas> patches before that are applied.
    >>
    >> could you please clarify whether
    >>
    >> f0d71b3dcb8332f7971b5f2363632573e6d9486a futex: Prevent attaching
    >> to kernel threads 866293ee54227584ffcb4a42f69c1f365974ba7f futex:
    >> Add another early deadlock detection check

    Greg> As people keep asking me this, I'll respond with, "why
    Greg> wouldn't you apply them"?

    Greg> They are going to be in the next kernel stable releases, along
    Greg> with the other 4 patches, so I recommend them for your custom
    Greg> kernels as well.

Thanks for the reply. I did read your earlier message. To answer your
question: I only apply patches that are absolutely necessary to fix a
known problem. 

"known problem" to whom?  :)

With that kind of attitude, you are going to miss a lot of valuable
kernel fixes for issues.  I'd recommend using a stable kernel release
instead, but hey, it's your systems...

Want to make sure the changed stuff doesn't lead to a regression
somewhere else.

Nothing is ever "sure" in software.

Futex stuff is a central component in the kernel ... I can't judge
about any possible side effects from reading the code ...  and this
kernel is going on a number of production clusters.

Test it out first, like you should any update.  There are futex test
suites out there, run them yourself to verify that nothing is broken.
As for if it fixes potentially future problems that others might not
know about, well, that's a gamble on everyone's part, right?

Anyway, I've applied all the (2+4) patches to our 3.12. 

Why are you "stuck" at 3.12?  There is someone still maintaining
3.12-stable, why not rely on those releases if you want that kernel
version, instead of rolling your own?

thanks,

greg k-h


Current thread: