From 402a715f82313384ef4606660c32d8678c79f197 Mon Sep 17 00:00:00 2001 From: DRC Date: Sat, 22 Nov 2014 22:09:30 +0000 Subject: [PATCH] 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.4.x@1426 632fc199-4ca6-4c93-a231-07263d6284db --- ChangeLog.txt | 12 ++++++++++++ jchuff.c | 11 ++++++++++- 2 files changed, 22 insertions(+), 1 deletion(-) diff --git a/ChangeLog.txt b/ChangeLog.txt index f0d126b..58b5208 100644 --- a/ChangeLog.txt +++ b/ChangeLog.txt @@ -35,6 +35,18 @@ before it treated the image as a grayscale JPEG. [8] cjpeg, djpeg, and jpegtran now accept an argument of -version, which will print the library version and exit. +[9] Referring to 1.4 beta1 [15], 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.90 (1.4 beta1) ================== diff --git a/jchuff.c b/jchuff.c index 447209a..a5c0a1f 100644 --- a/jchuff.c +++ b/jchuff.c @@ -408,7 +408,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) { \ -- 2.49.0