oss-sec mailing list archives
Re: How GNU/Linux distros deal with offset2lib attack?
From: Greg KH <greg () kroah com>
Date: Fri, 19 Dec 2014 14:11:53 -0800
On Fri, Dec 19, 2014 at 10:41:28PM +0100, Mathias Krause wrote:
On 18 December 2014 at 22:50, Greg KH <greg () kroah 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 () treenet 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
Current thread:
- Re: How GNU/Linux distros deal with offset2lib attack?, (continued)
- Re: How GNU/Linux distros deal with offset2lib attack? Shawn (Dec 08)
- Re: How GNU/Linux distros deal with offset2lib attack? Greg KH (Dec 07)
- Re: How GNU/Linux distros deal with offset2lib attack? Daniel Micay (Dec 07)
- Re: How GNU/Linux distros deal with offset2lib attack? Greg KH (Dec 07)
- Re: How GNU/Linux distros deal with offset2lib attack? Lionel Debroux (Dec 07)
- Re: How GNU/Linux distros deal with offset2lib attack? Lionel Debroux (Dec 18)
- Re: How GNU/Linux distros deal with offset2lib attack? Amos Jeffries (Dec 18)
- Re: How GNU/Linux distros deal with offset2lib attack? Mathias Krause (Dec 18)
- Re: How GNU/Linux distros deal with offset2lib attack? Greg KH (Dec 18)
- Re: How GNU/Linux distros deal with offset2lib attack? Mathias Krause (Dec 19)
- Re: How GNU/Linux distros deal with offset2lib attack? Greg KH (Dec 19)
- Re: How GNU/Linux distros deal with offset2lib attack? Greg KH (Dec 18)