aboutsummaryrefslogtreecommitdiff
path: root/bzdiff
diff options
context:
space:
mode:
authorMark Wielaard <mark@klomp.org>2019-07-03 01:28:11 +0200
committerMark Wielaard <mark@klomp.org>2019-07-09 23:29:44 +0200
commitb07b105d1b66e32760095e3602261738443b9e13 (patch)
tree186e47e404d16a7492ba1c26d23c8988961a5756 /bzdiff
parent13d8bce0393ca21cbca1e8ba7692466a64fd46dd (diff)
downloadbzip2-b07b105d1b66e32760095e3602261738443b9e13.tar.gz
bzip2-b07b105d1b66e32760095e3602261738443b9e13.tar.bz2
bzip2-b07b105d1b66e32760095e3602261738443b9e13.zip
Accept as many selectors as the file format allows.
But ignore any larger than the theoretical maximum, BZ_MAX_SELECTORS. The theoretical maximum number of selectors depends on the maximum blocksize (900000 bytes) and the number of symbols (50) that can be encoded with a different Huffman tree. BZ_MAX_SELECTORS is 18002. But the bzip2 file format allows the number of selectors to be encoded with 15 bits (because 18002 isn't a factor of 2 and doesn't fit in 14 bits). So the file format maximum is 32767 selectors. Some bzip2 encoders might actually have written out more selectors than the theoretical maximum because they rounded up the number of selectors to some convenient factor of 8. The extra 14766 selectors can never be validly used by the decompression algorithm. So we can read them, but then discard them. This is effectively what was done (by accident) before we added a check for nSelectors to be at most BZ_MAX_SELECTORS to mitigate CVE-2019-12900. The extra selectors were written out after the array inside the EState struct. But the struct has extra space allocated after the selector arrays of 18060 bytes (which is larger than 14766). All of which will be initialized later (so the overwrite of that space with extra selector values would have been harmless).
Diffstat (limited to 'bzdiff')
0 files changed, 0 insertions, 0 deletions