]> git.kernelconcepts.de Git - karo-tx-linux.git/commit
XZ: Fix incorrect XZ_BUF_ERROR
authorLasse Collin <lasse.collin@tukaani.org>
Wed, 21 Sep 2011 14:30:50 +0000 (17:30 +0300)
committerGreg Kroah-Hartman <gregkh@suse.de>
Mon, 3 Oct 2011 18:40:37 +0000 (11:40 -0700)
commitac82a9c88d9e0db9f33ed03517c3e3925ceae634
tree3314552f3dd20344a0552e91edbc35462a080cb6
parentb73077a5fce232f3e95099f3bd9c084ab320aa85
XZ: Fix incorrect XZ_BUF_ERROR

commit 9c1f8594df4814ebfd6822ca3c9444fb3445888d upstream.

xz_dec_run() could incorrectly return XZ_BUF_ERROR if all of the
following was true:

 - The caller knows how many bytes of output to expect and only provides
   that much output space.

 - When the last output bytes are decoded, the caller-provided input
   buffer ends right before the LZMA2 end of payload marker.  So LZMA2
   won't provide more output anymore, but it won't know it yet and thus
   won't return XZ_STREAM_END yet.

 - A BCJ filter is in use and it hasn't left any unfiltered bytes in the
   temp buffer.  This can happen with any BCJ filter, but in practice
   it's more likely with filters other than the x86 BCJ.

This fixes <https://bugzilla.redhat.com/show_bug.cgi?id=735408> where
Squashfs thinks that a valid file system is corrupt.

This also fixes a similar bug in single-call mode where the uncompressed
size of a block using BCJ + LZMA2 was 0 bytes and caller provided no
output space.  Many empty .xz files don't contain any blocks and thus
don't trigger this bug.

This also tweaks a closely related detail: xz_dec_bcj_run() could call
xz_dec_lzma2_run() to decode into temp buffer when it was known to be
useless.  This was harmless although it wasted a minuscule number of CPU
cycles.

Signed-off-by: Lasse Collin <lasse.collin@tukaani.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
lib/xz/xz_dec_bcj.c