[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20140606152120.GA13400@kroah.com>
Date: Fri, 6 Jun 2014 08:21:20 -0700
From: Greg KH <greg@...ah.com>
To: oss-security@...ts.openwall.com
Subject: Re: Linux kernel futex local privilege escalation
(CVE-2014-3153)
On Fri, Jun 06, 2014 at 04:24:23PM +0200, rf@...eap.de wrote:
> >>>>> "Greg" == Greg KH <greg@...ah.com> writes:
>
> Greg> On Fri, Jun 06, 2014 at 11:11:42AM +0200, rf@...eap.de wrote:
> >> >>>>> "Thomas" == Thomas Gleixner <tglx@...utronix.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
Powered by blists - more mailing lists
Please check out the
Open Source Software Security Wiki, which is counterpart to this
mailing list.
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
