[Pkg-tigervnc-devel] Bug#768369: Acknowledgement ([libjpeg62-turbo] [DOS] Stack smashing)

[DRC]

I want exactly what I asked for:  a way to reproduce this issue. 
Currently I cannot.  A backtrace from your machine is not helpful, as it 
does not tell me anything regarding how the library is being used by 
ImageMagick.


On 11/7/14 11:26 AM, roucaries bastien wrote:
> On Fri, Nov 7, 2014 at 4:57 PM, DRC <dcommander at users.sourceforge.net> wrote:
>> Happy to fix it, but I need to be able to reproduce it first, using only
>> libjpeg-turbo.  Currently I cannot.  I tried running
>
> Here a backtrace, do you want to get some argument of the call function ?
> #0  0x00007ffff7067107 in __GI_raise (sig=sig at entry=6) at
> ../nptl/sysdeps/unix/sysv/linux/raise.c:56
> #1  0x00007ffff70684e8 in __GI_abort () at abort.c:89
> #2  0x00007ffff70a5044 in __libc_message (do_abort=do_abort at entry=2,
> fmt=fmt at entry=0x7ffff719568b "*** %s ***: %s terminated\n") at
> ../sysdeps/posix/libc_fatal.c:175
> #3  0x00007ffff7128137 in __GI___fortify_fail
> (msg=msg at entry=0x7ffff7195673 "stack smashing detected") at
> fortify_fail.c:31
> #4  0x00007ffff7128100 in __stack_chk_fail () at stack_chk_fail.c:28
> #5  0x00007ffff39d7553 in encode_mcu_huff (cinfo=0x7fffffff42e0,
> MCU_data=0x63a450) at jchuff.c:641
> #6  0x00007ffff39ca717 in compress_output (cinfo=0x7fffffff42e0,
> input_buf=<optimized out>) at jccoefct.c:381
> #7  0x00007ffff39ca006 in jpeg_finish_compress (cinfo=0x7fffffff42e0)
> at jcapimin.c:183
> #8  0x00007ffff3c222d0 in WriteJPEGImage (image_info=0x2c0c,
> image=0x2c0c) at ../../coders/jpeg.c:2810
> #9  0x00007ffff79aa1bc in WriteImage (image_info=0x60e530,
> image=0x626070) at ../../magick/constitute.c:1114
> #10 0x00007ffff79aa87a in WriteImages (image_info=<optimized out>,
> images=<optimized out>, filename=<optimized out>, exception=0x604e10)
> at ../../magick/constitute.c:1327
> #11 0x00007ffff763bc81 in ConvertImageCommand (image_info=0x4, argc=5,
> argv=0x604810, metadata=0xffffffffffffffff, exception=0x0) at
> ../../wand/convert.c:3215
> #12 0x00007ffff76a5ee7 in MagickCommandGenesis
> (image_info=image_info at entry=0x604f90, command=0x400810
> <ConvertImageCommand at plt>, argc=argc at entry=5,
> argv=argv at entry=0x7fffffffe118,
>      metadata=metadata at entry=0x0, exception=exception at entry=0x604e10)
> at ../../wand/mogrify.c:168
> #13 0x0000000000400887 in ConvertMain (argv=0x7fffffffe118, argc=5) at
> ../../utilities/convert.c:81
> #14 main (argc=5, argv=0x7fffffffe118) at ../../utilities/convert.c:92
>
>>
>>    jpegtran -optimize -rotate 270 003632r270.jpg >out.jpg
>>
>> and
>>
>>    jpegtran -progressive -optimize -rotate 270 003632r270.jpg >out.jpg
>>
>> with valgrind, and no issues were detected.
>>
>> I also tried the convert command line listed above, and with my (admittedly
>> older) version of ImageMagick, no issues were detected. This leads me to
>> suspect an issue with ImageMagick, not libjpeg-turbo. Furthermore, Mozilla
>> bangs on the -optimize switch a tremendous amount, since that switch is
>> enabled by default in their mozjpeg encoder (mozjpeg is focused on getting
>> the absolute best compression ratio possible-- at the expense of like a 50x
>> drop in performance-- so they enable progressive & optimize by default, as
>> well as include other extensions like jpgcrush and trellis coding that
>> aren't in libjpeg-turbo.)  Furthermore, there is nothing about the optimized
>> (multi-pass) Huffman coding feature that is different between libjpeg-turbo
>> and libjpeg, so if this is genuinely a bug in libjpeg-turbo, it is likely to
>> exist in libjpeg as well.  Our optimizations affect only single-pass Huffman
>> coding.
>>