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

Date:	Wed, 11 Mar 2009 17:39:26 -0700 (PDT)
From:	Linus Torvalds <torvalds@...ux-foundation.org>
To:	Phillip Lougher <phillip@...gher.demon.co.uk>
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?

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".

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.

		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/