[pdftex] Use of uninitialized memory when writing SMask in write_png_rgb_alpha

David Fifield david at bamsoftware.com
Wed Mar 29 01:24:53 CEST 2017

The function write_png_rgb_alpha allocates twice as much memory as is
necessary for the smask buffer. The second half of the buffer is left
uninitialized and the whole buffer is copied to the output PDF file.

I think the bug is in texk/web2c/pdftexdir/writepng.c, where a "/ 2"
should be "/ 4"; i.e., 1 in 4 bytes is an alpha byte:
    smask_size = (png_get_rowbytes(png_ptr(img), png_info(img)) / 2)
                 * png_get_image_height(png_ptr(img), png_info(img));
Interestingly, texk/web2c/luatexdir/image/writepng.w gets it right:
    smask_size = (int) ((png_get_rowbytes(png_p, info_p) / 4) * png_get_image_height(png_p, info_p));

I attached files that demonstrate the error when run in Valgrind. The
first pair, test-rgb.tex and img-rgb.png, don't have the error because
the image doesn't have an alpha channel and goes through write_png_rgb
rather than write_png_rgb_alpha:
	$ valgrind pdflatex test-rgb
The second pair, test-rgba.tex and img-rgba.png, show many errors. (The
stack trace says write_png_gray_alpha rather than write_png_rgb_alpha,
but I believe that is an optimization artifact.)
	$ valgrind pdflatex test-rgba
	<img-rgba.png, id=1, 100.375pt x 100.375pt> <use img-rgba.png> [1{/var/lib/texm
	f/fonts/map/pdftex/updmap/pdftex.map} <./img-rgba.png==11091== Conditional jump or move depends on uninitialised value(s)
	==11091==    at 0x4C300D3: memcpy at GLIBC_2.2.5 (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
	==11091==    by 0x506E425: ??? (in /lib/x86_64-linux-gnu/libz.so.1.2.8)
	==11091==    by 0x506EE67: ??? (in /lib/x86_64-linux-gnu/libz.so.1.2.8)
	==11091==    by 0x506FE53: deflate (in /lib/x86_64-linux-gnu/libz.so.1.2.8)
	==11091==    by 0x199F5A: writezip (writezip.c:71)
	==11091==    by 0x152179: pdfflush.part.39 (pdftex0.c:18948)
	==11091==    by 0x16B1E4: pdfflush (pdftex0.c:19087)
	==11091==    by 0x16B1E4: pdfendstream (pdftex0.c:19085)
	==11091==    by 0x18FA99: write_png_gray_alpha (writepng.c:288)
	==11091==    by 0x18FA99: write_png (writepng.c:652)
	==11091==    by 0x18A836: writeimage (writeimg.c:370)
	==11091==    by 0x16BB78: zpdfwriteimage (pdftex0.c:22285)
	==11091==    by 0x16D794: zpdfshipout (pdftex0.c:24722)
	==11091==    by 0x17F65C: maincontrol (pdftex0.c:38501)
In order to get line numbers in the stack trace, I had to install the
"texlive-binaries-dbgsym" Debian package.

Another way to verify is to set
Then you can see that the pixel data of the 100×100 image has
	/Length 30000
But the SMask data is twice as big as it should be:
	/Length 20000

Here is my version information:
	pdfTeX 3.14159265-2.6-1.40.17 (TeX Live 2016/Debian)
	kpathsea version 6.2.2
	Copyright 2016 Han The Thanh (pdfTeX) et al.
	There is NO warranty.  Redistribution of this software is
	covered by the terms of both the pdfTeX copyright and
	the Lesser GNU General Public License.
	For more information about these matters, see the file
	named COPYING and the pdfTeX source.
	Primary author of pdfTeX: Han The Thanh (pdfTeX) et al.
	Compiled with libpng 1.6.28; using libpng 1.6.28
	Compiled with zlib 1.2.8; using zlib 1.2.8
	Compiled with poppler version 0.48.0

Debian bug #796490 appears to be about this same issue:

I discovered this problem while trying to make a reproducible PDF. I was
unable to get reproducibility of a particular document even after
following the suggestions of https://tex.stackexchange.com/a/313605:
The non-reproducibility was caused by uninitialized memory being copied
to the output file.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: test-rgb.tex
Type: text/x-tex
Size: 104 bytes
Desc: not available
URL: <http://tug.org/pipermail/pdftex/attachments/20170328/81ad07de/attachment.bin>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: img-rgb.png
Type: image/png
Size: 559 bytes
Desc: not available
URL: <http://tug.org/pipermail/pdftex/attachments/20170328/81ad07de/attachment.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: test-rgba.tex
Type: text/x-tex
Size: 105 bytes
Desc: not available
URL: <http://tug.org/pipermail/pdftex/attachments/20170328/81ad07de/attachment-0001.bin>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: img-rgba.png
Type: image/png
Size: 578 bytes
Desc: not available
URL: <http://tug.org/pipermail/pdftex/attachments/20170328/81ad07de/attachment-0001.png>

More information about the pdftex mailing list