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:
@@ -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
|
||||
=====
|
||||
|
||||
11
jchuff.c
11
jchuff.c
@@ -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) { \
|
||||
|
||||
Reference in New Issue
Block a user