[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <20141219221153.GA16721@kroah.com>
Date: Fri, 19 Dec 2014 14:11:53 -0800
From: Greg KH <greg@...ah.com>
To: oss-security@...ts.openwall.com
Subject: Re: How GNU/Linux distros deal with offset2lib attack?
On Fri, Dec 19, 2014 at 10:41:28PM +0100, Mathias Krause wrote:
> On 18 December 2014 at 22:50, Greg KH <greg@...ah.com> wrote:
> > On Thu, Dec 18, 2014 at 11:36:03AM +0100, Mathias Krause wrote:
> >> On 18 December 2014 at 10:35, Amos Jeffries <squid3@...enet.co.nz> wrote:
> >> > On 18/12/2014 9:24 p.m., Lionel Debroux wrote:
> >> All wrong. As Lionel wrote, the code assigns the variable before
> >> reading it. So no data is meant to persist between multiple calls to
> >> this function. However, if max8925_probe() gets called concurrently,
> >> the 'chip' pointer may change beneath one of the threads -- not good.
> >> So this is clearly a fix.
> >
> > But that function can not be called concurrently, so this doesn't
> > matter.
>
> Thanks for clarifying this. Still, it's worth to fix this, no? Even if
> this is not a bug in a sense that it would be exploitable in any way,
> it's obfuscating things.
I agree.
> >> > People using PaX code are trusting that they have done the analysis,
> >>
> >> Obviously they did.
> >
> > Someone got it wrong :)
>
> Fixing obfuscated code is wrong -- got it.
Um, no, this was supposed to be a "security" fix, and it wasn't, it's
just a code cleanup. A very valid code cleanup that we take all the
time in the kernel tree, but the analysis seems to have been wrong as
you have pointed out :)
> >> > but that very code not being in mainline means there is possibly no
> >> > hard proof of that.
> >>
> >> You're wrong, again. No-one submitted the fix to LKML, that's the reason.
> >
> > And if they did, they would have gotten the review I just gave.
>
> So you advocate for leaving the 'static' in place just because "it's
> not a bug"? That's ridiculous!
> Can you please point me to the part in Documentation/CodingStyle were
> it says obfuscated code is the preferred kernel coding style? Thanks.
The code isn't "obfuscated" at all, it's obvious what it does. It's not
obvious why the structure is static, and it doesn't have to be, but
that's not obscure at all.
It's something to clean up, great, submit it, we take this stuff all the
time. But trying to make a big deal out of it seems silly, when there
is no bug being fixed.
> It looks like none of the 5000 kernel developers has a strong interest
> in security.
I love hyperbole, don't you?
bah humbug,
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.
