#82 Uninitialized read from buffer allocated by jinit_upsampler

[Luke Alonso]

The attached image produces an unintialized read warning from valgrind 100% of the time. The program does a simple read -> decompress -> compress -> write, no transformation of the image data. The problem appears to be in the decoder, since we get similar errors if we try to write the output data as a PNG instead. No other images produce this warning.

If we memset the upsampler color_buf to 0 after alloc_sarray in jinit_upsampler, the warning disappears.

Unclear if it's a real problem.

Observed with libjpeg-turbo 1.3.1, on Linux and OS X.

Use of uninitialised value of size 8
==74796== at 0x10003F546: encode_one_block (jchuff.c:485)
==74796== by 0x10003ECFE: encode_mcu_huff (jchuff.c:616)
==74796== by 0x100038BFF: compress_output (jccoefct.c:381)
==74796== by 0x10003781E: jpeg_finish_compress (jcapimin.c:183)

Uninitialised value was created by a heap allocation
==74796== at 0x1001C85CB: malloc
==74796== by 0x100097548: jpeg_get_large (jmemnobs.c:57)
==74796== by 0x100095D1F: alloc_large (jmemmgr.c:378)
==74796== by 0x100095F4F: alloc_sarray (jmemmgr.c:455)
==74796== by 0x10008271D: jinit_upsampler (jdsample.c:490)
==74796== by 0x10007ABD7: master_selection (jdmaster.c:542)
==74796== by 0x10007A59B: jinit_master_decompress (jdmaster.c:734)
==74796== by 0x1000663E5: jpeg_start_decompress (jdapistd.c:45)

[DRC]

Please re-upload the image in a tarball. SourceForge's bug tracker unfortunately recompresses every JPEG that is attached to a bug report, so the recompressed version doesn't necessarily reproduce the bug (in this case, it doesn't.)

Please upload a small program that can be used to demonstrate the issue.

Please indicate the version of valgrind you are using.

Can you confirm whether it occurs when the library is built without SIMD? (configure --without-simd)?

I suspect that this isn't really an issue, particularly if it just occurs with SIMD. valgrind historically has had problems detecting whether our SSE2 code was actually affecting particular memory regions.

[Luke Alonso]

We actually just tracked it down to the SSE color space conversions. valgrind think it's reading into the padding region of color_buf. I'll close this - thanks for the reply!

[Luke Alonso]

Or, since I can't - feel free to close. :)