[gs-commits] ghostpdl branch, master, updated. jbig2dec-0.14-1895-g7ff87e8

The ghostpdl branch, master has been updated
       via  7ff87e872888da0f5cfd392b3f8b90fa7ad0e27c (commit)
      from  7e50bda19813d11555ff1ab4f7cb5c3e55ff0653 (commit)

----------------------------------------------------------------------
commit 7ff87e872888da0f5cfd392b3f8b90fa7ad0e27c
Author: Ken Sharp <[email protected]>
Date:   Tue Nov 19 12:26:18 2019 +0000

    Fix the Lexmark contributed device
    
    Bug #701905 "heap-buffer-overflow at contrib/gdevlx32.c:1509 in convbuf"
    
    The problem here is actually much earlier. In encode_bw_buf() there is a
    comment (line 1771) about starting before the first non-white pixels
    in order to "give the head a little more room to accelerate properly".
    
    If the first non-white pixel is less than 3 pixels from the left edge
    of the raster, this will cause the calculation of 'left' to become
    negative. It seems to me this will immediately corrupt the data. In
    addition right is calculated in a similar fashion, if right is also
    close to the right edge of the raster, then we can end up with numcols
    being more than the width of the raster.
    
    This argument is passed to convbuf() and that tries to read off the end
    of the input data, because numcols exceeds the bytes in the raster.
    
    I'm pretty dubious about this whole piece of code but since I don't
    have a printer to test with I'm reluctant to make major changes. This
    commit simply clamps left to 0 and right to the right edge of the
    raster. The comment implies that the extra spacing probably isn't useful
    and certainly suggests that removing it won't be harmful.

diff --git a/contrib/gdevlx32.c b/contrib/gdevlx32.c
index 20b01fa..652668d 100644
--- a/contrib/gdevlx32.c
+++ b/contrib/gdevlx32.c
@@ -1726,6 +1726,19 @@ encode_bw_buf(pagedata *gendata)
                 left = gendata->left - csep;
                 right = gendata->right + 2*csep;
         }
+        /* Make sure we don't try to write data to the left of 0, or the right of the
+         * media. In the absence of a physical pritner to try this on, we'll have to
+         * hope the comment above is correct and we can simply not bother with the
+         * optimisation for accelerating the print head. The right edge one seems
+         * bonkers, why would we care about accelerating the head when we have
+         * already started printing ?
+         * This is to fix bug #701905, accessing beyond the end of gendata->outdata
+         * in 'convbuf' because right - left > number bytes in scan line.
+         */
+        if (left < 0)
+            left = 0;
+        if (right > gendata->numbytes)
+            right = gendata->numbytes;
 
         /* Number of columns in a full row */
         numcols = right - left;


Summary of changes:
 contrib/gdevlx32.c | 13 +++++++++++++
 1 file changed, 13 insertions(+)