summaryrefslogtreecommitdiff
path: root/lib/zlib/inffast.c
AgeCommit message (Collapse)Author
2024-07-19zlib: Fix big performance regressionChristophe Leroy
Commit 340fdf1303dc ("zlib: Port fix for CVE-2016-9841 to U-Boot") brings a big performance regression in inflate_fast(), which leads to watchdog timer reset on powerpc 8xx. It looks like that commit does more than what it describe, it especially removed an important optimisation that was doing copies using halfwords instead of bytes. That unexpected change multiplied by almost 4 the time spent in inflate_fast() and increased by 40% the overall time needed to uncompress linux kernel image. So partially revert that commit but keep post incrementation as it is the initial purpose of said commit. [trini: Combine assorted patches in to this one, just restoring the performance commit] Fixes: 340fdf1303dc ("zlib: Port fix for CVE-2016-9841 to U-Boot") Signed-off-by: Christophe Leroy <christophe.leroy@csgroup.eu> Acked-by: Michal Simek <michal.simek@amd.com> Signed-off-by: Tom Rini <trini@konsulko.com>
2024-07-05Revert "Revert "Merge patch series "zlib: Address CVE-2016-9841"""Tom Rini
Now that the release has happened, bring back the update to zlib. This reverts commit bbacdd3ef7762fbdeab43ceea5205d1fd0f25bbd. Signed-off-by: Tom Rini <trini@konsulko.com>
2024-06-30Revert "Merge patch series "zlib: Address CVE-2016-9841""Tom Rini
This series brings our zlib code more up to date. However, it drops an important performance improvement that is required on some of our supported platforms in order to boot Linux before the watchdog resets the system. Furthermore, the "post increment" version of this performance loop was not tested, so while we can fix it, it would then require re-testing all platforms. At this point in time, we will revert updating zlib (which has had a potential security issue since 2016) and fix this in the v2024.10 release. This reverts commit 4914263c9a14315390d3ccc4816cf3a94cfd156d, reversing changes made to ef8ef5f77c9a998f76a48277a883af1645b54117. Reported-by: Christophe Leroy <christophe.leroy@csgroup.eu> Signed-off-by: Tom Rini <trini@konsulko.com>
2024-04-12zlib: Port fix for CVE-2016-9841 to U-BootMichal Simek
The patch corresponds to zlib commit at https://github.com/madler/zlib/commit/9aaec95e82117c1cb0f9624264c3618fc380cecb which declares that it is fixing CVE-2016-9841. Here is c&p description from zlib: "Use post-increment only in inffast.c. An old inffast.c optimization turns out to not be optimal anymore with modern compilers, and furthermore was not compliant with the C standard, for which decrementing a pointer before its allocated memory is undefined. Per the recommendation of a security audit of the zlib code by Trail of Bits and TrustInSoft, in support of the Mozilla Foundation, this "optimization" was removed, in order to avoid the possibility of undefined behavior." Origin patch also updates the code when INFLATE_ALLOW_INVALID_DISTANCE_TOOFAR_ARRR is present but this code is not the part of U-Boot hence it is ignored. Also do not deal with state->sane variable which requires other changes which are also not the part of zlib. Commit 92faa8b10918 ("zlib: handle overflow while calculating available stream input size") is kept in inffast.c too not to break described case. Signed-off-by: Michal Simek <michal.simek@amd.com>
2024-04-12zlib: Rename write variable to wnext (window write index)Michal Simek
There is no particular patch/description which described the reason for this change but it was done as the part of zlib 1.2.3.5 release done by zlib commit d004b047838a ("zlib 1.2.3.5"). It is preparation for followup patch. Signed-off-by: Michal Simek <michal.simek@amd.com>
2024-04-12zlib: Rename this variable to here (current decoding table entry)Michal Simek
There is no particular patch/description which described the reason for this change but it was done as the part of zlib 1.2.3.5 release done by zlib commit 639be997883d ("zlib 1.2.3.3") It is preparation for followup patch. Signed-off-by: Michal Simek <michal.simek@amd.com>
2016-02-06Use correct spelling of "U-Boot"Bin Meng
Correct spelling of "U-Boot" shall be used in all written text (documentation, comments in source files etc.). Signed-off-by: Bin Meng <bmeng.cn@gmail.com> Reviewed-by: Heiko Schocher <hs@denx.de> Reviewed-by: Simon Glass <sjg@chromium.org> Reviewed-by: Minkyu Kang <mk7.kang@samsung.com>
2012-11-04lib/zlib: sparse fixesKim Phillips
define Z_NULL to (void *)0 include/u-boot/zlib.h to get rid of most of the NULL pointer warnings. inflate.c:942:1: warning: non-ANSI definition of function 'inflateEnd' inflate.c:9:1: warning: non-ANSI definition of function 'inflateReset' inflate.c:12:17: warning: Using plain integer as NULL pointer inflate.c:12:42: warning: Using plain integer as NULL pointer inflate.c:15:17: warning: Using plain integer as NULL pointer inflate.c:21:19: warning: Using plain integer as NULL pointer inflate.c:35:1: warning: non-ANSI definition of function 'inflateInit2_' inflate.c:38:20: warning: Using plain integer as NULL pointer inflate.c:41:17: warning: Using plain integer as NULL pointer inflate.c:42:17: warning: Using plain integer as NULL pointer inflate.c:50:18: warning: Using plain integer as NULL pointer inflate.c:65:23: warning: Using plain integer as NULL pointer inflate.c:69:21: warning: Using plain integer as NULL pointer inflate.c:78:1: warning: non-ANSI definition of function 'inflateInit_' inflate.c:86:1: warning: non-ANSI definition of function 'fixedtables' inflate.c:108:26: warning: Using plain integer as NULL pointer inflate.c:109:1: warning: non-ANSI definition of function 'updatewindow' inflate.c:112:30: warning: Using plain integer as NULL pointer inflate.c:339:1: warning: non-ANSI definition of function 'inflate' inflate.c:349:17: warning: Using plain integer as NULL pointer inflate.c:349:42: warning: Using plain integer as NULL pointer inflate.c:350:27: warning: Using plain integer as NULL pointer inflate.c:369:42: warning: Using plain integer as NULL pointer inflate.c:376:32: warning: Using plain integer as NULL pointer inflate.c:401:54: warning: Using plain integer as NULL pointer inflate.c:419:32: warning: Using plain integer as NULL pointer inflate.c:426:32: warning: Using plain integer as NULL pointer inflate.c:433:32: warning: Using plain integer as NULL pointer inflate.c:444:36: warning: Using plain integer as NULL pointer inflate.c:449:37: warning: Using plain integer as NULL pointer inflate.c:450:38: warning: Using plain integer as NULL pointer inflate.c:457:40: warning: Using plain integer as NULL pointer inflate.c:458:47: warning: Using plain integer as NULL pointer inflate.c:480:40: warning: Using plain integer as NULL pointer inflate.c:481:50: warning: Using plain integer as NULL pointer inflate.c:491:37: warning: Using plain integer as NULL pointer inflate.c:492:37: warning: Using plain integer as NULL pointer inflate.c:501:40: warning: Using plain integer as NULL pointer inflate.c:502:53: warning: Using plain integer as NULL pointer inflate.c:512:37: warning: Using plain integer as NULL pointer inflate.c:513:40: warning: Using plain integer as NULL pointer inflate.c:525:32: warning: Using plain integer as NULL pointer inflate.c:529:52: warning: Using plain integer as NULL pointer inflate.c:543:54: warning: Using plain integer as NULL pointer inflate.c:932:17: warning: Using plain integer as NULL pointer inflate.c:932:42: warning: Using plain integer as NULL pointer inflate.c:935:26: warning: Using plain integer as NULL pointer inflate.c:940:19: warning: Using plain integer as NULL pointer adler32.c:58:5: warning: non-ANSI definition of function 'adler32' adler32.c:81:16: warning: Using plain integer as NULL pointer zutil.c:53:9: warning: non-ANSI definition of function 'zcalloc' zutil.c:64:9: warning: non-ANSI definition of function 'zcfree' inffast.c:70:1: warning: non-ANSI definition of function 'inflate_fast' inftrees.c:33:1: warning: non-ANSI definition of function 'inflate_table' Signed-off-by: Kim Phillips <kim.phillips@freescale.com>
2011-10-28zlib: Fix integer cast of pointerSimon Glass
Fix to cast an integer to a pointer using uintptr_t. Signed-off-by: Simon Glass <sjg@chromium.org>
2011-10-17zlib: handle overflow while calculating available stream input sizeAnatolij Gustschin
If compressed data is located in sectors at the end of the flash and it's offset + input stream size > 0xFFFFFFFF, the uncompressing time is very long, since processing of the stream is done bytewise (and not blockwise) due to overflow in inflate_fast() while calculation and checking for enough input available. Check for this overflow condition and limit the available stream input size to the actually max. possible input size. This fixes the problem. The issue is easily reproduceable by placing a gziped bitmap in flash, e.g. at FFF80000, and running 'bmp' commands like 'bmp info FFF80000' or 'bmp display FFF80000'. The uncompressing can take up to 3 sec. whereas it should normaly take a fraction of a second. If the 'splashimage' environment variable points to this address, the booting time also increases significantly. Signed-off-by: Anatolij Gustschin <agust@denx.de>
2011-04-30zlib: split up to match original source treeMike Frysinger
While looking to upgrade to zlib-1.2.5, the current mondo merge of multiple files into a single was making things way more difficult than it should have been. Hard to pick out what has been changed to port it to U-Boot, been removed as useless, and bug fixes added after the fact. So split the single file up into the original file names, and merge non-essential changes back from the original tree (for some reason, style in code in a bunch of places was changed to U-Boot style even though this isn't "U-Boot" code). The original build style is retained -- we have a single zlib.c that includes all the other files, and that is the only file we compile. Signed-off-by: Mike Frysinger <vapier@gentoo.org>