linux-kernel - Re: [GIT-PULL] More Squashfs fixes for 2.6.29?

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] [day] [month] [year] [list]

Date:	Thu, 12 Mar 2009 00:59:01 +0000
From:	Phillip Lougher <phillip@...gher.demon.co.uk>
To:	Linus Torvalds <torvalds@...ux-foundation.org>
CC:	akpm@...ux-foundation.org, Geert.Uytterhoeven@...ycom.com,
	linux-kernel@...r.kernel.org, s.L-H@....de
Subject: Re: [GIT-PULL] More Squashfs fixes for 2.6.29?

Linus Torvalds wrote:
> 
> On Thu, 12 Mar 2009, Phillip Lougher wrote:
>> But I optimised the inner loop out because of the following logic:
>>
>> zlib_inflate always tries to make as much progress as possible
> 
> Is this strictly true? Your own bug report seems to say that it isn't.
> 
> Hmm. [ Goes back and looks. ] The zlib source code is a total piece of 
> mess, but it does seem like it only does "goto inf_leave" when it needs 
> more data (unless you ask for the "stop at block boundary", of course). Or 
> in the Z_STREAM_END case, or errors. 
> 
> But your bug report sounds very much like you got all the data already 
> (nothing available for output any more), but then didn't do the last CHECK 
> stage (== no output, but the input contains the 32-bit adler checksum and 
> the CHECK command). That would explain exactly the case of "a few extra 
> bytes at the input, despite not having any output left".

Yes, this is exactly what's happening.  Sorry if the bug report didn't
make it clear.

> 
> And if you don't do the CHECK stage, then you're missing a large part of 
> the corruption checking that zlib does.
> 
> So you should never exit based on whether you still need output. So that
> 
> 	if (msblk->stream.avail_out == 0) {
> 		..
> 		else if (msblk->stream.avail_in > 0
> 			BUG
> 
> really looks _wrong_. It's not a buggy situation at all to have no output 
> left to process, but still input in the input buffers. It may well just 
> mean that you ended up having the CHECK part of the zlib buffer in a new 
> input buffer.

Yes the check is pretty bogus.  I'm about to send an improved patch
that gets rid of this check (just relying on zlib to error if we've
got no more output buffers, and it wants to output).

I'll also put some more info into the commit indicating the problem
it's fixing.

Thanks

Phillip

> 
> 		Linus
> 


--
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/