summaryrefslogtreecommitdiff
path: root/lib/lzma/LzmaTools.c
AgeCommit message (Collapse)Author
2015-01-14lzma: fix buffer bound check error furtherSimon Glass
Commit 4d3b8a0d fixed a problem with lzma decompress where it would run out of bytes to decompress. The algorithm needs to know how many uncompressed bytes it is expected to produce. However, the fix introduced a potential buffer overrun, and causes the compression test to fail (test_compression command in sandbox). The correct fix seems to be to use the minimum of the expected number of uncompressed bytes and the amount of output space available. That way things work normally when there is enough space, and return an error (without overrunning available space) when there is not. Signed-off-by: Antonios Vamporakis <ant@area128.com> CC: Kees Cook <keescook@chromium.org> CC: Simon Glass <sjg@chromium.org> CC: Daniel Schwierzeck <daniel.schwierzeck@gmail.com> CC: Luka Perkov <luka@openwrt.org> Signed-off-by: Simon Glass <sjg@chromium.org>
2014-06-11LzmaTools: don't self assign valuesJeroen Hofstee
It seems the code tries to trick the compiler the argument is actually used. However compilers became too smart to fool them so easily an now warn. Gcc and clang don't seem to emit a warning when the argument is unused. If so it should be decorated with unused / (void). Signed-off-by: Jeroen Hofstee <jeroen@myspectrum.nl>
2014-01-14lzma: fix buffer bound check errorAntonios Vamporakis
Variable uncompressedSize references the space available, while outSizeFull is the actual expected uncompressed size. Using the wrong value causes LzmaDecode to return SZ_ERROR_INPUT_EOF. Problem was introduced in commit afca294. While at it add additional debug message. Signed-off-by: Antonios Vamporakis <ant@area128.com> CC: Kees Cook <keescook@chromium.org> CC: Simon Glass <sjg@chromium.org> CC: Daniel Schwierzeck <daniel.schwierzeck@gmail.com> CC: Luka Perkov <luka@openwrt.org>
2013-09-03lzma: correctly bounds-check output bufferKees Cook
The output buffer size must be correctly passed to the lzma decoder or there is a risk of overflowing memory during decompression. Switching to the LZMA_FINISH_END mode means nothing is left in an unknown state once the buffer becomes full. Signed-off-by: Kees Cook <keescook@chromium.org> Acked-by: Simon Glass <sjg@chromium.org>
2013-07-24Add GPL-2.0+ SPDX-License-Identifier to source filesWolfgang Denk
Signed-off-by: Wolfgang Denk <wd@denx.de> [trini: Fixup common/cmd_io.c] Signed-off-by: Tom Rini <trini@ti.com>
2012-03-28lzma: fix printf warningsMike Frysinger
Fix size_t printf format warnings: LzmaTools.c: In function 'lzmaBuffToBuffDecompress': LzmaTools.c:110:5: warning: format '%x' expects type 'unsigned int', but argument 2 has type 'SizeT' LzmaTools.c:111:5: warning: format '%x' expects type 'unsigned int', but argument 2 has type 'SizeT' Signed-off-by: Mike Frysinger <vapier@gentoo.org>
2011-10-27GCC4.6: Squash warnings in LzmaTools.cMarek Vasut
LzmaTools.c: In function 'lzmaBuffToBuffDecompress': LzmaTools.c:70:5: warning: format '%lx' expects type 'long unsigned int', but argument 2 has type 'unsigned char *' LzmaTools.c:71:5: warning: format '%lx' expects type 'long unsigned int', but argument 2 has type 'unsigned char *' LzmaTools.c:72:5: warning: format '%lx' expects type 'long unsigned int', but argument 2 has type 'unsigned char *' LzmaTools.c:73:5: warning: format '%lx' expects type 'long unsigned int', but argument 2 has type 'unsigned char *' LzmaTools.c:74:5: warning: format '%lx' expects type 'long unsigned int', but argument 2 has type 'unsigned char *' LzmaTools.c:110:5: warning: format '%lx' expects type 'long unsigned int', but argument 2 has type 'SizeT' LzmaTools.c:111:5: warning: format '%lx' expects type 'long unsigned int', but argument 2 has type 'SizeT' Signed-off-by: Marek Vasut <marek.vasut@gmail.com> Cc: Wolfgang Denk <wd@denx.de> Cc: Simon Glass <sjg@chromium.org> Cc: Mike Frysinger <vapier@gentoo.org>
2010-04-13Rename lib_generic/ to lib/Peter Tyser
Now that the other architecture-specific lib directories have been moved out of the top-level directory there's not much reason to have the '_generic' suffix on the common lib directory. Signed-off-by: Peter Tyser <ptyser@xes-inc.com>