Fix Huffman local buffer overrun discovered by Debian developers when attempting to transform a junk image using ImageMagick:

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=768369


git-svn-id: svn+ssh://svn.code.sf.net/p/libjpeg-turbo/code/branches/1.3.x@1427 632fc199-4ca6-4c93-a231-07263d6284db
This commit is contained in:
DRC
2014-11-22 22:24:41 +00:00
parent ef263e3e83
commit bb383b4175
2 changed files with 22 additions and 1 deletions

View File

@@ -44,6 +44,18 @@ for such images are ignored by the decompressor. However, the TurboJPEG API
was being too rigid and was expecting the sampling factors to be equal to 1
before it treated the image as a grayscale JPEG.
[9] Referring to [5] above, another extremely rare circumstance was discovered
under which the Huffman encoder's local buffer can be overrun when a buffered
destination manager is being used and an extremely-high-frequency block
(basically junk image data) is being encoded. Even though the Huffman local
buffer was increased from 128 bytes to 136 bytes to address the previous
issue, the new issue caused even the larger buffer to be overrun. Further
analysis reveals that, in the absolute worst case (such as setting alternating
AC coefficients to 32767 and -32768 in the JPEG scanning order), the Huffman
encoder can produce encoded blocks that approach double the size of the
unencoded blocks. Thus, the Huffman local buffer was increased to 256 bytes,
which should prevent any such issue from re-occurring in the future.
1.3.1
=====

View File

@@ -391,7 +391,16 @@ dump_buffer (working_state * state)
#endif
#define BUFSIZE (DCTSIZE2 * 2) + 8
/* Although it is exceedingly rare, it is possible for a Huffman-encoded
* coefficient block to be larger than the 128-byte unencoded block. For each
* of the 64 coefficients, PUT_BITS is invoked twice, and each invocation can
* theoretically store 16 bits (for a maximum of 2048 bits or 256 bytes per
* encoded block.) If, for instance, one artificially sets the AC
* coefficients to alternating values of 32767 and -32768 (using the JPEG
* scanning order-- 1, 8, 16, etc.), then this will produce an encoded block
* larger than 200 bytes.
*/
#define BUFSIZE (DCTSIZE2 * 4)
#define LOAD_BUFFER() { \
if (state->free_in_buffer < BUFSIZE) { \