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

[roucaries bastien]

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.
>