Fix Huffman local buffer overrun discovered by Debian developers when attempting...

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

diff --git a/ChangeLog.txt b/ChangeLog.txt
index f0d126b40e79073190174b7e7e67c84a47f163ce..58b5208c302d9874347e0d091732c9e72ec48036 100644 (file)
--- 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 447209a003fa2f20df8e81f4532df3879b2d0439..a5c0a1fda33612b12daa78904e9409287549f8f8 100644 (file)
--- 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) { \