Hi, I just noticed that there's a wierd condition in a nested loop inside decompress_unlzma.c. To be more precise, the lzma main decoding looks like this: while (global_pos + buffer_pos < header.dst_size) { ... do { ... } while (len != 0 && buffer_pos < header.dst_size); } I'm interested in the do { } while condition (busybox-1.17.2.tar.bz2, archival/libunarchive/decompress_unlzma.c, around line 449). That code is in busybox since the beginning of time. buffer_pos is guaranteed to be inside [0 .. header.dict_size) interval at all times, and its comparison against header.dst_size seems meaningless. The total number of written bytes is given by global_pos + buffer_pos; (see main while loop).
> buffer_pos is guaranteed to be inside [0 .. header.dict_size) interval Maybe. It's not exactly obvious from the code. More to the point: what do you want to be done with this code?
Created attachment 2593 [details] unlzma buffer_pos fix
From what I've seen, buffer_pos only changes this way: buffer[buffer_pos++] = previous_byte; if (buffer_pos == header.dict_size) { buffer_pos = 0; /* flush dictionary */ } and it looks like header.dst_size should be compared against (global_pos + buffer_pos), not against buffer_pos (see attached patch). Or maybe I am just missing something.
Added comments to address this easier - if it's a real bug: commit 81071e6872eeb9e47b938d5d6fd82056aaebdd2e Author: Denys Vlasenko <vda.linux@googlemail.com> Date: Fri Feb 28 15:42:10 2014 +0100 unlzma: add comments about possible bug from BZ 2689