linux-kernel - Re: 2.6.22-rc1-mm1

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <4665AD8B.80506@shadowen.org>
Date:	Tue, 05 Jun 2007 19:38:03 +0100
From:	Andy Whitcroft <apw@...dowen.org>
To:	"H. Peter Anvin" <hpa@...or.com>
CC:	Mel Gorman <mel@....ul.ie>,
	Andrew Morton <akpm@...ux-foundation.org>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
	Steve Fox <drfickle@...ibm.com>
Subject: Re: 2.6.22-rc1-mm1

H. Peter Anvin wrote:
> Andy Whitcroft wrote:
>> I think that my debugging says that newsetup got the compressed kernel
>> and decompressor into memory ok and execution passed to it normally.
>> But I cannot figure out where the corruption is coming from.  I tried
>> annotating the gzip decompressor to see if the input and output buffers
>> were overlapping at any time and that debug said no (unsure how reliable
>> that is).  And yet at some point the output image is munched up.
>>
>> One last piece of information.  The decompressor also always seems to
>> get to the end of the input stream in exactly the right place without
>> reporting any kind of error, that is with exactly 8 bytes left over for
>> the length and crc checks.  Which given the context sensitive nature of
>> the algorithm tends to imply the input stream was ok for the whole
>> duration of the decompress.  Yet the output stream is badly broken.
>>
>> Anyone got any wacky suggestions ...
>>
> 
> It definitely sounds like a memory clobber of some sort.
> 
> Usual suspects, in addition to the input/output buffers you already
> looked at, would be the heap and the stack.  Finding where the stack
> pointer lives would be my first, instinctive guess.

The stack seems to be where it should be and seems to stay pretty much
in the same place as it should.  Adding checks for the heap also seem to
stay within bounds.  I've tried making the stack and the heap 64k to no
effect.

Moving the kernel to other places in memory seems to kill the decode
completely during gunzip() which may be a hint I am not sure.

This thing is trying to ruin my mind.

-apw
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/