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
|
was being too rigid and was expecting the sampling factors to be equal to 1
|
||||||
before it treated the image as a grayscale JPEG.
|
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
|
1.3.1
|
||||||
=====
|
=====
|
||||||
|
|||||||
11
jchuff.c
11
jchuff.c
@@ -391,7 +391,16 @@ dump_buffer (working_state * state)
|
|||||||
#endif
|
#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() { \
|
#define LOAD_BUFFER() { \
|
||||||
if (state->free_in_buffer < BUFSIZE) { \
|
if (state->free_in_buffer < BUFSIZE) { \
|
||||||
|
|||||||
Reference in New Issue
Block a user