]> git.kernelconcepts.de Git - karo-tx-uboot.git/commitdiff
zlib: handle overflow while calculating available stream input size
authorAnatolij Gustschin <agust@denx.de>
Sat, 15 Oct 2011 06:32:52 +0000 (06:32 +0000)
committerWolfgang Denk <wd@denx.de>
Mon, 17 Oct 2011 19:45:35 +0000 (21:45 +0200)
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>
lib/zlib/inffast.c

index 8e823df4cf158bc0e2e23d9b15c5914c68d5d472..4834b0c86e00c3d4e6f0f217fa1d9f8f0dbdd5a0 100644 (file)
@@ -100,6 +100,14 @@ unsigned start;         /* inflate()'s starting value for strm->avail_out */
     state = (struct inflate_state FAR *)strm->state;
     in = strm->next_in - OFF;
     last = in + (strm->avail_in - 5);
+    if (in > last && strm->avail_in > 5) {
+        /*
+         * overflow detected, limit strm->avail_in to the
+         * max. possible size and recalculate last
+         */
+        strm->avail_in = 0xffffffff - (unsigned int)in;
+        last = in + (strm->avail_in - 5);
+    }
     out = strm->next_out - OFF;
     beg = out - (start - strm->avail_out);
     end = out + (strm->avail_out - 257);