xz: fix incorrect XZ_BUF_ERROR
authorLasse Collin <lasse.collin@tukaani.org>
Wed, 27 Feb 2013 15:39:56 +0000 (16:39 +0100)
committerDenys Vlasenko <vda.linux@googlemail.com>
Wed, 27 Feb 2013 15:39:56 +0000 (16:39 +0100)
commitc3045edec221876596fe910901191720d8f55986
tree9fb80f2e681f44a070db742ba0b3131de6556508
parenta1ae2b75a71b4b99948aa0f9a15cf1de52bb40d6
xz: fix incorrect XZ_BUF_ERROR

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.
Thanks to Jindrich Novy for telling me that such a bug report
exists, Phillip Lougher for providing excellent debug info,
and other people on #fedora-ppc.

This also fixes a similar bug in single-call mode where the
uncompressed size of a XZ 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: Denys Vlasenko <vda.linux@googlemail.com>
archival/libarchive/unxz/xz_dec_bcj.c