libjpeg-turbo: CVE-2014-9092: [DOS] Stack smashing

Debian Bug report logs - #768369
libjpeg-turbo: CVE-2014-9092: [DOS] Stack smashing

Toggle useless messages

---

Message #5 received at submit@bugs.debian.org (full text, mbox, reply):

Package: libjpeg62-turbo
Version: 1:1.3.1-10
Severity: serious
Tags: security
X-Debbugs-CC: secure-testing-team@lists.alioth.debian.org
control: affects -1 imagemagick

Special crafted jpeg files lead to  stack smashing and lead to at least a dos (maybe remote due to imagick).

Source file are here http://tapani.tarvainen.info/linux/convertbug/

I am going to ask a CVE

Bastien

 LANG=C convert -rotate 270 003632r270.jpg junk.jpg 2>&1 
*** stack smashing detected ***: convert terminated
======= Backtrace: =========
/lib/x86_64-linux-gnu/libc.so.6(+0x7303f)[0x7f03eafad03f]
/lib/x86_64-linux-gnu/libc.so.6(__fortify_fail+0x37)[0x7f03eb030137]
/lib/x86_64-linux-gnu/libc.so.6(__fortify_fail+0x0)[0x7f03eb030100]
/usr/lib/x86_64-linux-gnu/libjpeg.so.62(+0x11553)[0x7f03e78df553]
/usr/lib/x86_64-linux-gnu/libjpeg.so.62(+0x4717)[0x7f03e78d2717]
/usr/lib/x86_64-linux-gnu/libjpeg.so.62(jpeg_finish_compress+0x96)[0x7f03e78d2006]
/usr/lib/x86_64-linux-gnu/ImageMagick-6.8.9/modules-Q16/coders/jpeg.so(+0x52d0)[0x7f03e7b2a2d0]
/usr/lib/x86_64-linux-gnu/libMagickCore-6.Q16.so.2(WriteImage+0x50c)[0x7f03eb8b21bc]
/usr/lib/x86_64-linux-gnu/libMagickCore-6.Q16.so.2(WriteImages+0x1ea)[0x7f03eb8b287a]
/usr/lib/x86_64-linux-gnu/libMagickWand-6.Q16.so.2(ConvertImageCommand+0x2811)[0x7f03eb543c81]
/usr/lib/x86_64-linux-gnu/libMagickWand-6.Q16.so.2(MagickCommandGenesis+0x707)[0x7f03eb5adee7]
convert[0x400887]
/lib/x86_64-linux-gnu/libc.so.6(__libc_start_main+0xf5)[0x7f03eaf5bb45]
convert[0x4008db]
======= Memory map: ========
00400000-00401000 r-xp 00000000 08:03 1185315                            /usr/lib/x86_64-linux-gnu/ImageMagick-6.8.9/bin-Q16/convert
00600000-00601000 r--p 00000000 08:03 1185315                            /usr/lib/x86_64-linux-gnu/ImageMagick-6.8.9/bin-Q16/convert
00601000-00602000 rw-p 00001000 08:03 1185315                            /usr/lib/x86_64-linux-gnu/ImageMagick-6.8.9/bin-Q16/convert
0193b000-01997000 rw-p 00000000 00:00 0                                  [heap]
7f03e23e9000-7f03e23ea000 ---p 00000000 00:00 0 
7f03e23ea000-7f03e525c000 rw-p 00000000 00:00 0                          [stack:30025]
7f03e6a53000-7f03e78ce000 rw-p 00000000 00:00 0 
7f03e78ce000-7f03e7913000 r-xp 00000000 08:03 1183749                    /usr/lib/x86_64-linux-gnu/libjpeg.so.62.1.0
7f03e7913000-7f03e7b13000 ---p 00045000 08:03 1183749                    /usr/lib/x86_64-linux-gnu/libjpeg.so.62.1.0
7f03e7b13000-7f03e7b14000 r--p 00045000 08:03 1183749                    /usr/lib/x86_64-linux-gnu/libjpeg.so.62.1.0
7f03e7b14000-7f03e7b15000 rw-p 00046000 08:03 1183749                    /usr/lib/x86_64-linux-gnu/libjpeg.so.62.1.0
7f03e7b15000-7f03e7b25000 rw-p 00000000 00:00 0 
7f03e7b25000-7f03e7b30000 r-xp 00000000 08:03 1228159                    /usr/lib/x86_64-linux-gnu/ImageMagick-6.8.9/modules-Q16/coders/jpeg.so
7f03e7b30000-7f03e7d2f000 ---p 0000b000 08:03 1228159                    /usr/lib/x86_64-linux-gnu/ImageMagick-6.8.9/modules-Q16/coders/jpeg.so
7f03e7d2f000-7f03e7d30000 r--p 0000a000 08:03 1228159                    /usr/lib/x86_64-linux-gnu/ImageMagick-6.8.9/modules-Q16/coders/jpeg.so
7f03e7d30000-7f03e7d31000 rw-p 0000b000 08:03 1228159                    /usr/lib/x86_64-linux-gnu/ImageMagick-6.8.9/modules-Q16/coders/jpeg.so
7f03e7d31000-7f03e7d36000 r-xp 00000000 08:03 1186647                    /usr/lib/x86_64-linux-gnu/libXdmcp.so.6.0.0
7f03e7d36000-7f03e7f35000 ---p 00005000 08:03 1186647                    /usr/lib/x86_64-linux-gnu/libXdmcp.so.6.0.0
7f03e7f35000-7f03e7f36000 rw-p 00004000 08:03 1186647                    /usr/lib/x86_64-linux-gnu/libXdmcp.so.6.0.0
7f03e7f36000-7f03e7f39000 r-xp 00000000 08:03 1179923                    /usr/lib/x86_64-linux-gnu/libXau.so.6.0.0
7f03e7f39000-7f03e8138000 ---p 00003000 08:03 1179923                    /usr/lib/x86_64-linux-gnu/libXau.so.6.0.0
7f03e8138000-7f03e8139000 r--p 00002000 08:03 1179923                    /usr/lib/x86_64-linux-gnu/libXau.so.6.0.0
7f03e8139000-7f03e813a000 rw-p 00003000 08:03 1179923                    /usr/lib/x86_64-linux-gnu/libXau.so.6.0.0
7f03e813a000-7f03e81a6000 r-xp 00000000 08:03 1050253                    /lib/x86_64-linux-gnu/libpcre.so.3.13.1
7f03e81a6000-7f03e83a6000 ---p 0006c000 08:03 1050253                    /lib/x86_64-linux-gnu/libpcre.so.3.13.1
7f03e83a6000-7f03e83a7000 r--p 0006c000 08:03 1050253                    /lib/x86_64-linux-gnu/libpcre.so.3.13.1
7f03e83a7000-7f03e83a8000 rw-p 0006d000 08:03 1050253                    /lib/x86_64-linux-gnu/libpcre.so.3.13.1
7f03e83a8000-7f03e83ab000 r-xp 00000000 08:03 1053883                    /lib/x86_64-linux-gnu/libdl-2.19.so
7f03e83ab000-7f03e85aa000 ---p 00003000 08:03 1053883                    /lib/x86_64-linux-gnu/libdl-2.19.so
7f03e85aa000-7f03e85ab000 r--p 00002000 08:03 1053883                    /lib/x86_64-linux-gnu/libdl-2.19.so
7f03e85ab000-7f03e85ac000 rw-p 00003000 08:03 1053883                    /lib/x86_64-linux-gnu/libdl-2.19.so
7f03e85ac000-7f03e85ca000 r-xp 00000000 08:03 1184766                    /usr/lib/x86_64-linux-gnu/libxcb.so.1.1.0
7f03e85ca000-7f03e87c9000 ---p 0001e000 08:03 1184766                    /usr/lib/x86_64-linux-gnu/libxcb.so.1.1.0
7f03e87c9000-7f03e87ca000 r--p 0001d000 08:03 1184766                    /usr/lib/x86_64-linux-gnu/libxcb.so.1.1.0
7f03e87ca000-7f03e87cb000 rw-p 0001e000 08:03 1184766                    /usr/lib/x86_64-linux-gnu/libxcb.so.1.1.0
7f03e87cb000-7f03e87f1000 r-xp 00000000 08:03 1049399                    /lib/x86_64-linux-gnu/libpng12.so.0.50.0
7f03e87f1000-7f03e89f0000 ---p 00026000 08:03 1049399                    /lib/x86_64-linux-gnu/libpng12.so.0.50.0
7f03e89f0000-7f03e89f1000 r--p 00025000 08:03 1049399                    /lib/x86_64-linux-gnu/libpng12.so.0.50.0
7f03e89f1000-7f03e89f2000 rw-p 00026000 08:03 1049399                    /lib/x86_64-linux-gnu/libpng12.so.0.50.0
7f03e89f2000-7f03e8a19000 r-xp 00000000 08:03 1049345                    /lib/x86_64-linux-gnu/libexpat.so.1.6.0
7f03e8a19000-7f03e8c19000 ---p 00027000 08:03 1049345                    /lib/x86_64-linux-gnu/libexpat.so.1.6.0
7f03e8c19000-7f03e8c1b000 r--p 00027000 08:03 1049345                    /lib/x86_64-linux-gnu/libexpat.so.1.6.0
7f03e8c1b000-7f03e8c1c000 rw-p 00029000 08:03 1049345                    /lib/x86_64-linux-gnu/libexpat.so.1.6.0
7f03e8c1c000-7f03e8d28000 r-xp 00000000 08:03 1049471                    /lib/x86_64-linux-gnu/libglib-2.0.so.0.4200.0
7f03e8d28000-7f03e8f28000 ---p 0010c000 08:03 1049471                    /lib/x86_64-linux-gnu/libglib-2.0.so.0.4200.0
7f03e8f28000-7f03e8f29000 r--p 0010c000 08:03 1049471                    /lib/x86_64-linux-gnu/libglib-2.0.so.0.4200.0
7f03e8f29000-7f03e8f2a000 rw-p 0010d000 08:03 1049471                    /lib/x86_64-linux-gnu/libglib-2.0.so.0.4200.0
7f03e8f2a000-7f03e8f2b000 rw-p 00000000 00:00 0 
7f03e8f2b000-7f03e8f41000 r-xp 00000000 08:03 1052661                    /lib/x86_64-linux-gnu/libgcc_s.so.1
7f03e8f41000-7f03e9140000 ---p 00016000 08:03 1052661                    /lib/x86_64-linux-gnu/libgcc_s.so.1
7f03e9140000-7f03e9141000 rw-p 00015000 08:03 1052661                    /lib/x86_64-linux-gnu/libgcc_s.so.1
7f03e9141000-7f03e9157000 r-xp 00000000 08:03 1180591                    /usr/lib/x86_64-linux-gnu/libgomp.so.1.0.0
7f03e9157000-7f03e9356000 ---p 00016000 08:03 1180591                    /usr/lib/x86_64-linux-gnu/libgomp.so.1.0.0
7f03e9356000-7f03e9357000 rw-p 00015000 08:03 1180591                    /usr/lib/x86_64-linux-gnu/libgomp.so.1.0.0
7f03e9357000-7f03e9457000 r-xp 00000000 08:03 1053951                    /lib/x86_64-linux-gnu/libm-2.19.so
7f03e9457000-7f03e9656000 ---p 00100000 08:03 1053951                    /lib/x86_64-linux-gnu/libm-2.19.so
7f03e9656000-7f03e9657000 r--p 000ff000 08:03 1053951                    /lib/x86_64-linux-gnu/libm-2.19.so
7f03e9657000-7f03e9658000 rw-p 00100000 08:03 1053951                    /lib/x86_64-linux-gnu/libm-2.19.so
7f03e9658000-7f03e9661000 r-xp 00000000 08:03 1185079                    /usr/lib/x86_64-linux-gnu/libltdl.so.7.3.0
7f03e9661000-7f03e9860000 ---p 00009000 08:03 1185079                    /usr/lib/x86_64-linux-gnu/libltdl.so.7.3.0
7f03e9860000-7f03e9861000 r--p 00008000 08:03 1185079                    /usr/lib/x86_64-linux-gnu/libltdl.so.7.3.0
7f03e9861000-7f03e9862000 rw-p 00009000 08:03 1185079                    /usr/lib/x86_64-linux-gnu/libltdl.so.7.3.0
7f03e9862000-7f03e987c000 r-xp 00000000 08:03 1049497                    /lib/x86_64-linux-gnu/libz.so.1.2.8
7f03e987c000-7f03e9a7b000 ---p 0001a000 08:03 1049497                    /lib/x86_64-linux-gnu/libz.so.1.2.8
7f03e9a7b000-7f03e9a7c000 r--p 00019000 08:03 1049497                    /lib/x86_64-linux-gnu/libz.so.1.2.8
7f03e9a7c000-7f03e9a7d000 rw-p 0001a000 08:03 1049497                    /lib/x86_64-linux-gnu/libz.so.1.2.8
7f03e9a7d000-7f03e9a8c000 r-xp 00000000 08:03 1050090                    /lib/x86_64-linux-gnu/libbz2.so.1.0.4
7f03e9a8c000-7f03e9c8b000 ---p 0000f000 08:03 1050090                    /lib/x86_64-linux-gnu/libbz2.so.1.0.4
7f03e9c8b000-7f03e9c8c000 r--p 0000e000 08:03 1050090                    /lib/x86_64-linux-gnu/libbz2.so.1.0.4
7f03e9c8c000-7f03e9c8d000 rw-p 0000f000 08:03 1050090                    /lib/x86_64-linux-gnu/libbz2.so.1.0.4
7f03e9c8d000-7f03e9dc9000 r-xp 00000000 08:03 1182096                    /usr/lib/x86_64-linux-gnu/libX11.so.6.3.0
7f03e9dc9000-7f03e9fc8000 ---p 0013c000 08:03 1182096                    /usr/lib/x86_64-linux-gnu/libX11.so.6.3.0
7f03e9fc8000-7f03e9fca000 r--p 0013b000 08:03 1182096                    /usr/lib/x86_64-linux-gnu/libX11.so.6.3.0
7f03e9fca000-7f03e9fcf000 rw-p 0013d000 08:03 1182096                    /usr/lib/x86_64-linux-gnu/libX11.so.6.3.0
7f03e9fcf000-7f03e9fd0000 rw-p 00000000 00:00 0 
7f03e9fd0000-7f03e9fe1000 r-xp 00000000 08:03 1185171                    /usr/lib/x86_64-linux-gnu/libXext.so.6.4.0
7f03e9fe1000-7f03ea1e0000 ---p 00011000 08:03 1185171                    /usr/lib/x86_64-linux-gnu/libXext.so.6.4.0
7f03ea1e0000-7f03ea1e1000 r--p 00010000 08:03 1185171                    /usr/lib/x86_64-linux-gnu/libXext.so.6.4.0
7f03ea1e1000-7f03ea1e2000 rw-p 00011000 08:03 1185171                    /usr/lib/x86_64-linux-gnu/libXext.so.6.4.0
7f03ea1e2000-7f03ea285000 r-xp 00000000 08:03 1185063                    /usr/lib/x86_64-linux-gnu/libfreetype.so.6.11.1
7f03ea285000-7f03ea485000 ---p 000a3000 08:03 1185063                    /usr/lib/x86_64-linux-gnu/libfreetype.so.6.11.1
7f03ea485000-7f03ea48b000 r--p 000a3000 08:03 1185063                    /usr/lib/x86_64-linux-gnu/libfreetype.so.6.11.1
7f03ea48b000-7f03ea48c000 rw-p 000a9000 08:03 1185063                    /usr/lib/x86_64-linux-gnu/libfreetype.so.6.11.1
7f03ea48c000-7f03ea4c7000 r-xp 00000000 08:03 1185069                    /usr/lib/x86_64-linux-gnu/libfontconfig.so.1.8.0
7f03ea4c7000-7f03ea6c6000 ---p 0003b000 08:03 1185069                    /usr/lib/x86_64-linux-gnu/libfontconfig.so.1.8.0
7f03ea6c6000-7f03ea6c8000 r--p 0003a000 08:03 1185069                    /usr/lib/x86_64-linux-gnu/libfontconfig.so.1.8.0
7f03ea6c8000-7f03ea6c9000 rw-p 0003c000 08:03 1185069                    /usr/lib/x86_64-linux-gnu/libfontconfig.so.1.8.0
7f03ea6c9000-7f03ea8b5000 r-xp 00000000 08:03 1192745                    /usr/lib/x86_64-linux-gnu/libfftw3.so.3.4.4
7f03ea8b5000-7f03eaab4000 ---p 001ec000 08:03 1192745                    /usr/lib/x86_64-linux-gnu/libfftw3.so.3.4.4
7f03eaab4000-7f03eaac8000 r--p 001eb000 08:03 1192745                    /usr/lib/x86_64-linux-gnu/libfftw3.so.3.4.4
7f03eaac8000-7f03eaac9000 rw-p 001ff000 08:03 1192745                    /usr/lib/x86_64-linux-gnu/libfftw3.so.3.4.4
7f03eaac9000-7f03eaae0000 r-xp 00000000 08:03 1187859                    /usr/lib/x86_64-linux-gnu/liblqr-1.so.0.3.2
7f03eaae0000-7f03eacdf000 ---p 00017000 08:03 1187859                    /usr/lib/x86_64-linux-gnu/liblqr-1.so.0.3.2
7f03eacdf000-7f03eace0000 rw-p 00016000 08:03 1187859                    /usr/lib/x86_64-linux-gnu/liblqr-1.so.0.3.2
7f03eace0000-7f03ead35000 r-xp 00000000 08:03 1180399                    /usr/lib/x86_64-linux-gnu/liblcms2.so.2.0.6
7f03ead35000-7f03eaf34000 ---p 00055000 08:03 1180399                    /usr/lib/x86_64-linux-gnu/liblcms2.so.2.0.6
7f03eaf34000-7f03eaf35000 r--p 00054000 08:03 1180399                    /usr/lib/x86_64-linux-gnu/liblcms2.so.2.0.6
7f03eaf35000-7f03eaf3a000 rw-p 00055000 08:03 1180399                    /usr/lib/x86_64-linux-gnu/liblcms2.so.2.0.6
7f03eaf3a000-7f03eb0d9000 r-xp 00000000 08:03 1054021                    /lib/x86_64-linux-gnu/libc-2.19.so
7f03eb0d9000-7f03eb2d9000 ---p 0019f000 08:03 1054021                    /lib/x86_64-linux-gnu/libc-2.19.so
7f03eb2d9000-7f03eb2dd000 r--p 0019f000 08:03 1054021                    /lib/x86_64-linux-gnu/libc-2.19.so
7f03eb2dd000-7f03eb2df000 rw-p 001a3000 08:03 1054021                    /lib/x86_64-linux-gnu/libc-2.19.so
7f03eb2df000-7f03eb2e3000 rw-p 00000000 00:00 0 
7f03eb2e3000-7f03eb2fb000 r-xp 00000000 08:03 1053940                    /lib/x86_64-linux-gnu/libpthread-2.19.so
7f03eb2fb000-7f03eb4fa000 ---p 00018000 08:03 1053940                    /lib/x86_64-linux-gnu/libpthread-2.19.so
7f03eb4fa000-7f03eb4fb000 r--p 00017000 08:03 1053940                    /lib/x86_64-linux-gnu/libpthread-2.19.so
7f03eb4fb000-7f03eb4fc000 rw-p 00018000 08:03 1053940                    /lib/x86_64-linux-gnu/libpthread-2.19.so
7f03eb4fc000-7f03eb500000 rw-p 00000000 00:00 0 
7f03eb500000-7f03eb622000 r-xp 00000000 08:03 1183729                    /usr/lib/x86_64-linux-gnu/libMagickWand-6.Q16.so.2.0.0
7f03eb622000-7f03eb821000 ---p 00122000 08:03 1183729                    /usr/lib/x86_64-linux-gnu/libMagickWand-6.Q16.so.2.0.0
7f03eb821000-7f03eb822000 r--p 00121000 08:03 1183729                    /usr/lib/x86_64-linux-gnu/libMagickWand-6.Q16.so.2.0.0
7f03eb822000-7f03eb826000 rw-p 00122000 08:03 1183729                    /usr/lib/x86_64-linux-gnu/libMagickWand-6.Q16.so.2.0.0
7f03eb826000-7f03eba70000 r-xp 00000000 08:03 1186997                    /usr/lib/x86_64-linux-gnu/libMagickCore-6.Q16.so.2.0.0
7f03eba70000-7f03ebc70000 ---p 0024a000 08:03 1186997                    /usr/lib/x86_64-linux-gnu/libMagickCore-6.Q16.so.2.0.0
7f03ebc70000-7f03ebc84000 r--p 0024a000 08:03 1186997                    /usr/lib/x86_64-linux-gnu/libMagickCore-6.Q16.so.2.0.0
7f03ebc84000-7f03ebcc5000 rw-p 0025e000 08:03 1186997                    /usr/lib/x86_64-linux-gnu/libMagickCore-6.Q16.so.2.0.0
7f03ebcc5000-7f03ebce4000 rw-p 00000000 00:00 0 
7f03ebce4000-7f03ebd04000 r-xp 00000000 08:03 1054431                    /lib/x86_64-linux-gnu/ld-2.19.so
7f03ebea8000-7f03ebeb5000 rw-p 00000000 00:00 0 
7f03ebf00000-7f03ebf04000 rw-p 00000000 00:00 0 
7f03ebf04000-7f03ebf05000 r--p 00020000 08:03 1054431                    /lib/x86_64-linux-gnu/ld-2.19.so
7f03ebf05000-7f03ebf06000 rw-p 00021000 08:03 1054431                    /lib/x86_64-linux-gnu/ld-2.19.so
7f03ebf06000-7f03ebf07000 rw-p 00000000 00:00 0 
7fffaecf1000-7fffaed12000 rw-p 00000000 00:00 0                          [stack]
7fffaeda0000-7fffaeda2000 r-xp 00000000 00:00 0                          [vdso]
7fffaeda2000-7fffaeda4000 r--p 00000000 00:00 0                          [vvar]
ffffffffff600000-ffffffffff601000 r-xp 00000000 00:00 0                  [vsyscall]
Abandon

---

Message #12 received at 768369@bugs.debian.org (full text, mbox, reply):

More information could be found here
http://www.imagemagick.org/discourse-server/viewtopic.php?f=3&t=26482&sid=81658bc2f51a8d9893279cd01e83783f

On Thu, Nov 6, 2014 at 10:21 PM, Debian Bug Tracking System
<owner@bugs.debian.org> wrote:
> Thank you for filing a new Bug report with Debian.
>
> This is an automatically generated reply to let you know your message
> has been received.
>
> Your message is being forwarded to the package maintainers and other
> interested parties for their attention; they will reply in due course.
>
> As you requested using X-Debbugs-CC, your message was also forwarded to
>   secure-testing-team@lists.alioth.debian.org
> (after having been given a Bug report number, if it did not have one).
>
> Your message has been sent to the package maintainer(s):
>  Debian TigerVNC Packaging Team <pkg-tigervnc-devel@lists.alioth.debian.org>
>
> If you wish to submit further information on this problem, please
> send it to 768369@bugs.debian.org.
>
> Please do not send mail to owner@bugs.debian.org unless you wish
> to report a problem with the Bug-tracking system.
>
> --
> 768369: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=768369
> Debian Bug Tracking System
> Contact owner@bugs.debian.org with problems

---

Message #17 received at 768369@bugs.debian.org (full text, mbox, reply):

Did anyone report that to the upstream? Since it affects multiple
distributions that should have been the first thing to do...

Cheers,
Ondrej

On Thu, Nov 6, 2014, at 22:22, roucaries bastien wrote:
> More information could be found here
> http://www.imagemagick.org/discourse-server/viewtopic.php?f=3&t=26482&sid=81658bc2f51a8d9893279cd01e83783f
> 
> On Thu, Nov 6, 2014 at 10:21 PM, Debian Bug Tracking System
> <owner@bugs.debian.org> wrote:
> > Thank you for filing a new Bug report with Debian.
> >
> > This is an automatically generated reply to let you know your message
> > has been received.
> >
> > Your message is being forwarded to the package maintainers and other
> > interested parties for their attention; they will reply in due course.
> >
> > As you requested using X-Debbugs-CC, your message was also forwarded to
> >   secure-testing-team@lists.alioth.debian.org
> > (after having been given a Bug report number, if it did not have one).
> >
> > Your message has been sent to the package maintainer(s):
> >  Debian TigerVNC Packaging Team <pkg-tigervnc-devel@lists.alioth.debian.org>
> >
> > If you wish to submit further information on this problem, please
> > send it to 768369@bugs.debian.org.
> >
> > Please do not send mail to owner@bugs.debian.org unless you wish
> > to report a problem with the Bug-tracking system.
> >
> > --
> > 768369: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=768369
> > Debian Bug Tracking System
> > Contact owner@bugs.debian.org with problems
> 


-- 
Ondřej Surý <ondrej@sury.org>
Knot DNS (https://www.knot-dns.cz/) – a high-performance DNS server

---

Message #22 received at 768369@bugs.debian.org (full text, mbox, reply):

[Message part 1 (text/plain, inline)]

Le 7 nov. 2014 10:14, "Ondřej Surý" <ondrej@sury.org> a écrit :
>
> Did anyone report that to the upstream? Since it affects multiple
> distributions that should have been the first thing to do...

I Sent a mail to upstream contact adress.

Bastien
>
> Cheers,
> Ondrej
>
> On Thu, Nov 6, 2014, at 22:22, roucaries bastien wrote:
> > More information could be found here
> >
http://www.imagemagick.org/discourse-server/viewtopic.php?f=3&t=26482&sid=81658bc2f51a8d9893279cd01e83783f
> >
> > On Thu, Nov 6, 2014 at 10:21 PM, Debian Bug Tracking System
> > <owner@bugs.debian.org> wrote:
> > > Thank you for filing a new Bug report with Debian.
> > >
> > > This is an automatically generated reply to let you know your message
> > > has been received.
> > >
> > > Your message is being forwarded to the package maintainers and other
> > > interested parties for their attention; they will reply in due course.
> > >
> > > As you requested using X-Debbugs-CC, your message was also forwarded
to
> > >   secure-testing-team@lists.alioth.debian.org
> > > (after having been given a Bug report number, if it did not have one).
> > >
> > > Your message has been sent to the package maintainer(s):
> > >  Debian TigerVNC Packaging Team <
pkg-tigervnc-devel@lists.alioth.debian.org>
> > >
> > > If you wish to submit further information on this problem, please
> > > send it to 768369@bugs.debian.org.
> > >
> > > Please do not send mail to owner@bugs.debian.org unless you wish
> > > to report a problem with the Bug-tracking system.
> > >
> > > --
> > > 768369: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=768369
> > > Debian Bug Tracking System
> > > Contact owner@bugs.debian.org with problems
> >
>
>
> --
> Ondřej Surý <ondrej@sury.org>
> Knot DNS (https://www.knot-dns.cz/) – a high-performance DNS server

[Message part 2 (text/html, inline)]

---

Message #27 received at 768369@bugs.debian.org (full text, mbox, reply):

Happy to fix it, but I need to be able to reproduce it first, using only 
libjpeg-turbo.  Currently I cannot.  I tried running

  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.

---

Message #32 received at 768369@bugs.debian.org (full text, mbox, reply):

On Fri, Nov 7, 2014 at 4:57 PM, DRC <dcommander@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@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@entry=2,
fmt=fmt@entry=0x7ffff719568b "*** %s ***: %s terminated\n") at
../sysdeps/posix/libc_fatal.c:175
#3  0x00007ffff7128137 in __GI___fortify_fail
(msg=msg@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@entry=0x604f90, command=0x400810
<ConvertImageCommand@plt>, argc=argc@entry=5,
argv=argv@entry=0x7fffffffe118,
    metadata=metadata@entry=0x0, exception=exception@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.
>

---

Message #37 received at 768369@bugs.debian.org (full text, mbox, reply):

On Fri, Nov 7, 2014 at 6:26 PM, roucaries bastien
<roucaries.bastien+debian@gmail.com> wrote:
> On Fri, Nov 7, 2014 at 4:57 PM, DRC <dcommander@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@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@entry=2,
> fmt=fmt@entry=0x7ffff719568b "*** %s ***: %s terminated\n") at
> ../sysdeps/posix/libc_fatal.c:175
> #3  0x00007ffff7128137 in __GI___fortify_fail
> (msg=msg@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@entry=0x604f90, command=0x400810
> <ConvertImageCommand@plt>, argc=argc@entry=5,
> argv=argv@entry=0x7fffffffe118,
>     metadata=metadata@entry=0x0, exception=exception@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

Here more information note that valgrind does not detect anything.
Maybe a compiler bug?
(gdb) down
#4  0x00007ffff7128100 in __stack_chk_fail () at stack_chk_fail.c:28
28      stack_chk_fail.c: Aucun fichier ou dossier de ce type.
(gdb) up
#5  0x00007ffff39d7553 in encode_mcu_huff (cinfo=0x7fffffff42e0,
MCU_data=0x63a450) at jchuff.c:641
641     jchuff.c: Aucun fichier ou dossier de ce type.
(gdb) display *cinfo
6: *cinfo = {err = 0x7fffffff4150, mem = 0x621550, progress = 0x0,
client_data = 0x7fffffff4200, is_decompressor = 0, global_state = 101,
dest = 0x63a040, image_width = 1944,
  image_height = 2592, input_components = 3, in_color_space = JCS_RGB,
input_gamma = 1, data_precision = 8, num_components = 3,
jpeg_color_space = JCS_YCbCr, comp_info = 0x61c450,
  quant_tbl_ptrs = {0x61c810, 0x61c8a0, 0x0, 0x0}, dc_huff_tbl_ptrs =
{0x61c930, 0x61cb70, 0x0, 0x0}, ac_huff_tbl_ptrs = {0x61ca50,
0x61cc90, 0x0, 0x0},
  arith_dc_L = '\000' <repeats 15 times>, arith_dc_U = '\001' <repeats
16 times>, arith_ac_K = '\005' <repeats 16 times>, num_scans = 1,
scan_info = 0x0, raw_data_in = 0, arith_code = 0,
  optimize_coding = 1, CCIR601_sampling = 0, smoothing_factor = 0,
dct_method = JDCT_FLOAT, restart_interval = 0, restart_in_rows = 0,
write_JFIF_header = 1, JFIF_major_version = 1 '\001',
  JFIF_minor_version = 1 '\001', density_unit = 1 '\001', X_density =
72, Y_density = 72, write_Adobe_marker = 0, next_scanline = 2592,
progressive_mode = 0, max_h_samp_factor = 2,
  max_v_samp_factor = 2, total_iMCU_rows = 162, comps_in_scan = 3,
cur_comp_info = {0x61c450, 0x61c4b0, 0x61c510, 0x0}, MCUs_per_row =
122, MCU_rows_in_scan = 162, blocks_in_MCU = 6,
  MCU_membership = {0, 0, 0, 0, 1, 2, 0, 0, 0, 0}, Ss = 0, Se = 63, Ah
= 0, Al = 0, master = 0x63a080, main = 0x63a6d0, prep = 0x63a140, coef
= 0x63a430, marker = 0x63a840,
  cconvert = 0x63a0b0, downsample = 0x63a0d0, fdct = 0x63a1e0, entropy
= 0x63a370, script_space = 0x0, script_space_size = 0}
(gdb) display *MCU_data
7: *MCU_data = (JBLOCKROW) 0x7ffff3014130
(gdb) down
down           down-silently
(gdb) down
down           down-silently
(gdb) down
#4  0x00007ffff7128100 in __stack_chk_fail () at stack_chk_fail.c:28
28      stack_chk_fail.c: Aucun fichier ou dossier de ce type.
(gdb) up
#5  0x00007ffff39d7553 in encode_mcu_huff (cinfo=0x7fffffff42e0,
MCU_data=0x63a450) at jchuff.c:641
641     jchuff.c: Aucun fichier ou dossier de ce type.
(gdb) up
#6  0x00007ffff39ca717 in compress_output (cinfo=0x7fffffff42e0,
input_buf=<optimized out>) at jccoefct.c:381
381     jccoefct.c: Aucun fichier ou dossier de ce type.
(gdb) display *cinfo
8: *cinfo = {err = 0x7fffffff4150, mem = 0x621550, progress = 0x0,
client_data = 0x7fffffff4200, is_decompressor = 0, global_state = 101,
dest = 0x63a040, image_width = 1944,
  image_height = 2592, input_components = 3, in_color_space = JCS_RGB,
input_gamma = 1, data_precision = 8, num_components = 3,
jpeg_color_space = JCS_YCbCr, comp_info = 0x61c450,
  quant_tbl_ptrs = {0x61c810, 0x61c8a0, 0x0, 0x0}, dc_huff_tbl_ptrs =
{0x61c930, 0x61cb70, 0x0, 0x0}, ac_huff_tbl_ptrs = {0x61ca50,
0x61cc90, 0x0, 0x0},
  arith_dc_L = '\000' <repeats 15 times>, arith_dc_U = '\001' <repeats
16 times>, arith_ac_K = '\005' <repeats 16 times>, num_scans = 1,
scan_info = 0x0, raw_data_in = 0, arith_code = 0,
  optimize_coding = 1, CCIR601_sampling = 0, smoothing_factor = 0,
dct_method = JDCT_FLOAT, restart_interval = 0, restart_in_rows = 0,
write_JFIF_header = 1, JFIF_major_version = 1 '\001',
  JFIF_minor_version = 1 '\001', density_unit = 1 '\001', X_density =
72, Y_density = 72, write_Adobe_marker = 0, next_scanline = 2592,
progressive_mode = 0, max_h_samp_factor = 2,
  max_v_samp_factor = 2, total_iMCU_rows = 162, comps_in_scan = 3,
cur_comp_info = {0x61c450, 0x61c4b0, 0x61c510, 0x0}, MCUs_per_row =
122, MCU_rows_in_scan = 162, blocks_in_MCU = 6,
  MCU_membership = {0, 0, 0, 0, 1, 2, 0, 0, 0, 0}, Ss = 0, Se = 63, Ah
= 0, Al = 0, master = 0x63a080, main = 0x63a6d0, prep = 0x63a140, coef
= 0x63a430, marker = 0x63a840,
  cconvert = 0x63a0b0, downsample = 0x63a0d0, fdct = 0x63a1e0, entropy
= 0x63a370, script_space = 0x0, script_space_size = 0}
(gdb) display *input_buf
9: *input_buf = <error: value has been optimized out>
(gdb) down
#5  0x00007ffff39d7553 in encode_mcu_huff (cinfo=0x7fffffff42e0,
MCU_data=0x63a450) at jchuff.c:641
641     jchuff.c: Aucun fichier ou dossier de ce type.
(gdb) up
#6  0x00007ffff39ca717 in compress_output (cinfo=0x7fffffff42e0,
input_buf=<optimized out>) at jccoefct.c:381
381     jccoefct.c: Aucun fichier ou dossier de ce type.
(gdb) up
#7  0x00007ffff39ca006 in jpeg_finish_compress (cinfo=0x7fffffff42e0)
at jcapimin.c:183
183     jcapimin.c: Aucun fichier ou dossier de ce type.
(gdb) display *input_buf
No symbol "input_buf" in current context.
(gdb) display *cinfo
10: *cinfo = {err = 0x7fffffff4150, mem = 0x621550, progress = 0x0,
client_data = 0x7fffffff4200, is_decompressor = 0, global_state = 101,
dest = 0x63a040, image_width = 1944,
  image_height = 2592, input_components = 3, in_color_space = JCS_RGB,
input_gamma = 1, data_precision = 8, num_components = 3,
jpeg_color_space = JCS_YCbCr, comp_info = 0x61c450,
  quant_tbl_ptrs = {0x61c810, 0x61c8a0, 0x0, 0x0}, dc_huff_tbl_ptrs =
{0x61c930, 0x61cb70, 0x0, 0x0}, ac_huff_tbl_ptrs = {0x61ca50,
0x61cc90, 0x0, 0x0},
  arith_dc_L = '\000' <repeats 15 times>, arith_dc_U = '\001' <repeats
16 times>, arith_ac_K = '\005' <repeats 16 times>, num_scans = 1,
scan_info = 0x0, raw_data_in = 0, arith_code = 0,
  optimize_coding = 1, CCIR601_sampling = 0, smoothing_factor = 0,
dct_method = JDCT_FLOAT, restart_interval = 0, restart_in_rows = 0,
write_JFIF_header = 1, JFIF_major_version = 1 '\001',
  JFIF_minor_version = 1 '\001', density_unit = 1 '\001', X_density =
72, Y_density = 72, write_Adobe_marker = 0, next_scanline = 2592,
progressive_mode = 0, max_h_samp_factor = 2,
  max_v_samp_factor = 2, total_iMCU_rows = 162, comps_in_scan = 3,
cur_comp_info = {0x61c450, 0x61c4b0, 0x61c510, 0x0}, MCUs_per_row =
122, MCU_rows_in_scan = 162, blocks_in_MCU = 6,
  MCU_membership = {0, 0, 0, 0, 1, 2, 0, 0, 0, 0}, Ss = 0, Se = 63, Ah
= 0, Al = 0, master = 0x63a080, main = 0x63a6d0, prep = 0x63a140, coef
= 0x63a430, marker = 0x63a840,
  cconvert = 0x63a0b0, downsample = 0x63a0d0, fdct = 0x63a1e0, entropy
= 0x63a370, script_space = 0x0, script_space_size = 0}
(gdb) up
#8  0x00007ffff3c222d0 in WriteJPEGImage (image_info=0x2c0c,
image=0x2c0c) at ../../coders/jpeg.c:2810
2810    ../../coders/jpeg.c: Aucun fichier ou dossier de ce type.
(gdb)

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

---

Message #42 received at 768369@bugs.debian.org (full text, mbox, reply):

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@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@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@entry=2,
> fmt=fmt@entry=0x7ffff719568b "*** %s ***: %s terminated\n") at
> ../sysdeps/posix/libc_fatal.c:175
> #3  0x00007ffff7128137 in __GI___fortify_fail
> (msg=msg@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@entry=0x604f90, command=0x400810
> <ConvertImageCommand@plt>, argc=argc@entry=5,
> argv=argv@entry=0x7fffffffe118,
>      metadata=metadata@entry=0x0, exception=exception@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.
>>

---

Message #47 received at 768369@bugs.debian.org (full text, mbox, reply):

On Fri, Nov 7, 2014 at 6:36 PM, DRC <dcommander@users.sourceforge.net> wrote:
> 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.

Did you try to compile libjpeg-turbo with -fstack-protector-all ggc
flags. Debian do it and thus detect stack overflow (valgrind is not at
help here).

BTW could you nevertheless get a glimpse at the last backtrace. I but
a watch point on the canary (I tried but because this function is
called a lot of time I may be missing something) using method [1]. It
seems the code that smash the code is at encode_one_block line 543:
 kloop(59);  kloop(52);  kloop(45);  kloop(38);  kloop(31);  kloop(39);

Here dissambling near smashing:
 0x00007ffff39cfcdf <+11087>: cmp    $0xff,%cl
   0x00007ffff39cfce2 <+11090>: je     0x7ffff39d6a2d <encode_mcu_huff+39069>
   0x00007ffff39cfce8 <+11096>: mov    %r11d,%ecx
   0x00007ffff39cfceb <+11099>: movslq %r10d,%r10
   0x00007ffff39cfcee <+11102>: add    %r11d,%edx
   0x00007ffff39cfcf1 <+11105>: shl    %cl,%rax
   0x00007ffff39cfcf4 <+11108>: mov    %r13d,%ecx
   0x00007ffff39cfcf7 <+11111>: add    %r13d,%edx
   0x00007ffff39cfcfa <+11114>: or     %r9,%rax
   0x00007ffff39cfcfd <+11117>: shl    %cl,%rax
   0x00007ffff39cfd00 <+11120>: or     %r10,%rax
   0x00007ffff39cfd03 <+11123>: movswl 0x5a(%r15),%r10d
   0x00007ffff39cfd08 <+11128>: test   %r10d,%r10d
   0x00007ffff39cfd0b <+11131>: je     0x7ffff39d5ae8 <encode_mcu_huff+35160>
   0x00007ffff39cfd11 <+11137>: mov    %r10d,%r9d
   0x00007ffff39cfd14 <+11140>: sar    $0x1f,%r9d
   0x00007ffff39cfd18 <+11144>: mov    %r9d,%ecx
   0x00007ffff39cfd1b <+11147>: lea    (%r10,%r9,1),%r11d
   0x00007ffff39cfd1f <+11151>: xor    %r10d,%ecx
   0x00007ffff39cfd22 <+11154>: sub    %r9d,%ecx
   0x00007ffff39cfd25 <+11157>: mov    %r11d,0x3c(%rsp)
   0x00007ffff39cfd2a <+11162>: xor    %r11d,%r11d
   0x00007ffff39cfd2d <+11165>: movslq %ecx,%rcx
   0x00007ffff39cfd30 <+11168>: movzbl (%r14,%rcx,1),%r13d
   0x00007ffff39cfd35 <+11173>: nopl   (%rax)
   0x00007ffff39cfd38 <+11176>: lea    0x0(%r13,%r11,1),%ecx
   0x00007ffff39cfd3d <+11181>: mov    %rbx,%r10
   0x00007ffff39cfd40 <+11184>: movslq %ecx,%rcx
   0x00007ffff39cfd43 <+11187>: movslq (%r8,%rcx,4),%r9
   0x00007ffff39cfd47 <+11191>: movsbl 0x400(%r8,%rcx,1),%r11d
   0x00007ffff39cfd50 <+11200>: mov    %r13d,%ecx
   0x00007ffff39cfd53 <+11203>: shl    %cl,%r10
   0x00007ffff39cfd56 <+11206>: sub    $0x1,%r10d
   0x00007ffff39cfd5a <+11210>: and    0x3c(%rsp),%r10d
   0x00007ffff39cfd5f <+11215>: cmp    $0x1f,%edx
   0x00007ffff39cfd62 <+11218>: jle    0x7ffff39cfdd8 <encode_mcu_huff+11336>
   0x00007ffff39cfd64 <+11220>: lea    -0x8(%rdx),%ecx
   0x00007ffff39cfd67 <+11223>: mov    %rax,%rbp
   0x00007ffff39cfd6a <+11226>: shr    %cl,%rbp
   0x00007ffff39cfd6d <+11229>: mov    %rbp,%rcx
   0x00007ffff39cfd70 <+11232>: mov    %bpl,(%rdi)
   0x00007ffff39cfd73 <+11235>: lea    0x1(%rdi),%rbp
   0x00007ffff39cfd77 <+11239>: cmp    $0xff,%cl
   0x00007ffff39cfd7a <+11242>: je     0x7ffff39d6c62 <encode_mcu_huff+39634>
   0x00007ffff39cfd80 <+11248>: lea    -0x10(%rdx),%ecx
   0x00007ffff39cfd83 <+11251>: mov    %rax,%rdi
   0x00007ffff39cfd86 <+11254>: shr    %cl,%rdi
   0x00007ffff39cfd89 <+11257>: mov    %rdi,%rcx
---Type <return> to continue, or q <return> to quit---
   0x00007ffff39cfd8c <+11260>: mov    %dil,0x0(%rbp)
=> 0x00007ffff39cfd90 <+11264>: lea    0x1(%rbp),%rdi
   0x00007ffff39cfd94 <+11268>: cmp    $0xff,%cl
   0x00007ffff39cfd97 <+11271>: je     0x7ffff39d6c55 <encode_mcu_huff+39621>
   0x00007ffff39cfd9d <+11277>: lea    -0x18(%rdx),%ecx
   0x00007ffff39cfda0 <+11280>: mov    %rax,%rbp
   0x00007ffff39cfda3 <+11283>: shr    %cl,%rbp
   0x00007ffff39cfda6 <+11286>: mov    %rbp,%rcx
   0x00007ffff39cfda9 <+11289>: mov    %bpl,(%rdi)
   0x00007ffff39cfdac <+11292>: lea    0x1(%rdi),%rbp
   0x00007ffff39cfdb0 <+11296>: cmp    $0xff,%cl
   0x00007ffff39cfdb3 <+11299>: je     0x7ffff39d6c48 <encode_mcu_huff+39608>
   0x00007ffff39cfdb9 <+11305>: sub    $0x20,%edx
   0x00007ffff39cfdbc <+11308>: mov    %rax,%rdi
   0x00007ffff39cfdbf <+11311>: mov    %edx,%ecx
   0x00007ffff39cfdc1 <+11313>: shr    %cl,%rdi
   0x00007ffff39cfdc4 <+11316>: mov    %rdi,%rcx
   0x00007ffff39cfdc7 <+11319>: mov    %dil,0x0(%rbp)
   0x00007ffff39cfdcb <+11323>: lea    0x1(%rbp),%rdi
   0x00007ffff39cfdcf <+11327>: cmp    $0xff,%cl
   0x00007ffff39cfdd2 <+11330>: je     0x7ffff39d6c3b <encode_mcu_huff+39595>
   0x00007ffff39cfdd8 <+11336>: mov    %r11d,%ecx
   0x00007ffff39cfddb <+11339>: movslq %r10d,%r10
   0x00007ffff39cfdde <+11342>: add    %r11d,%edx
   0x00007ffff39cfde1 <+11345>: shl    %cl,%rax
   0x00007ffff39cfde4 <+11348>: mov    %r13d,%ecx
   0x00007ffff39cfde7 <+11351>: add    %r13d,%edx
   0x00007ffff39cfdea <+11354>: or     %r9,%rax
   0x00007ffff39cfded <+11357>: shl    %cl,%rax
   0x00007ffff39cfdf0 <+11360>: or     %r10,%rax
   0x00007ffff39cfdf3 <+11363>: movswl 0x4c(%r15),%r10d
   0x00007ffff39cfdf8 <+11368>: test   %r10d,%r10d
   0x00007ffff39cfdfb <+11371>: je     0x7ffff39d5aa0 <encode_mcu_huff+35088>
   0x00007ffff39cfe01 <+11377>: mov    %r10d,%r9d
   0x00007ffff39cfe04 <+11380>: sar    $0x1f,%r9d
   0x00007ffff39cfe08 <+11384>: mov    %r9d,%ecx
   0x00007ffff39cfe0b <+11387>: lea    (%r10,%r9,1),%r11d
   0x00007ffff39cfe0f <+11391>: xor    %r10d,%ecx
   0x00007ffff39cfe12 <+11394>: xor    %r10d,%r10d
   0x00007ffff39cfe15 <+11397>: sub    %r9d,%ecx
   0x00007ffff39cfe18 <+11400>: mov    %r11d,0x3c(%rsp)
   0x00007ffff39cfe1d <+11405>: movslq %ecx,%rcx
   0x00007ffff39cfe20 <+11408>: movzbl (%r14,%rcx,1),%r13d
   0x00007ffff39cfe25 <+11413>: nopl   (%rax)
   0x00007ffff39cfe28 <+11416>: lea    0x0(%r13,%r10,1),%ecx
   0x00007ffff39cfe2d <+11421>: mov    %rbx,%r10
   0x00007ffff39cfe30 <+11424>: movslq %ecx,%rcx
   0x00007ffff39cfe33 <+11427>: movslq (%r8,%rcx,4),%r9


Here full backtrace of stack smashing

(gdb) bt
#0  0x00007ffff39cfd90 in encode_one_block (actbl=0x6462a0,
dctbl=<optimized out>, last_dc_val=<optimized out>,
block=0x7ffff301bbb0, state=0x7fffffff3e40) at jchuff.c:543
#1  encode_mcu_huff (cinfo=0x7fffffff42e0, MCU_data=0x63a450) at jchuff.c:616
#2  0x00007ffff39ca717 in compress_output (cinfo=0x7fffffff42e0,
input_buf=<optimized out>) at jccoefct.c:381
#3  0x00007ffff39ca006 in jpeg_finish_compress (cinfo=0x7fffffff42e0)
at jcapimin.c:183
#4  0x00007ffff3c222d0 in WriteJPEGImage (image_info=0x1fc0ffecc7fe,
image=0x8) at ../../coders/jpeg.c:2810
#5  0x00007ffff79aa1bc in WriteImage (image_info=0x60e530,
image=0x626070) at ../../magick/constitute.c:1114
#6  0x00007ffff79aa87a in WriteImages (image_info=<optimized out>,
images=<optimized out>, filename=<optimized out>, exception=0x604e10)
at ../../magick/constitute.c:1327
#7  0x00007ffff763bc81 in ConvertImageCommand (image_info=0x4, argc=5,
argv=0x604810, metadata=0x1fc0ffecc7fe, exception=0x6462a0) at
../../wand/convert.c:3215
#8  0x00007ffff76a5ee7 in MagickCommandGenesis
(image_info=image_info@entry=0x604f90, command=0x400810
<ConvertImageCommand@plt>, argc=argc@entry=5,
argv=argv@entry=0x7fffffffe118,
    metadata=metadata@entry=0x0, exception=exception@entry=0x604e10)
at ../../wand/mogrify.c:168
#9  0x0000000000400887 in ConvertMain (argv=0x7fffffffe118, argc=5) at
../../utilities/convert.c:81
#10 main (argc=5, argv=0x7fffffffe118) at ../../utilities/convert.c:92
(gdb) print *state
$18 = {next_output_byte = 0x645d8e
"SV\355\266\260\220\355\204\311Ĝ\312G\027\215i\342\a", free_in_buffer
= 18, cur = {put_buffer = 10172277107327458490, put_bits = 34,
last_dc_val = {-999,
      -13, -8, 0}}, cinfo = 0x7fffffff42e0}
(gdb) list $rip
Undefined convenience variable or function "$rip" not defined.
(gdb) list *$rip
0x7ffff39cfd90 is in encode_mcu_huff (jchuff.c:543).
538     in jchuff.c
(gdb) print *actbl
$19 = {ehufco = {26, 0, 10, 120, 4092, 65516, 65519, 65522, 65525,
65529, 100992517, 117769735, 84346118, 67438344, 118163204, 101123844,
117901064, 4, 27, 506, 65520, 65531, 65530,
    84280581, 101057795, 101058054, 84215044, 101254661, 101123333,
84346374, 101057283, 84280838, 117966854, 11, 121, 2044, 65534,
84478214, 84149509, 67569160, 118097409, 101321224,
    84280327, 134546693, 50529802, 117900548, 151127305, 101254666,
117900548, 12, 248, 8188, 50595333, 117900291, 33817864, 117965569,
134481157, 67240968, 101188612, 84149765, 117770251,
    100993035, 101189383, 134743814, 100992520, 28, 507, 65517,
134874630, 151586307, 67569413, 84280580, 67373064, 101189381,
101058569, 117835270, 168428805, 134678538, 67372552,
    117966598, 100992260, 58, 1018, 65523, 117835529, 84215046,
50594307, 67372291, 168495365, 117966599, 117704201, 134678279,
84609030, 117900802, 84346888, 236981504, 67437826, 59, 2045,
    65526, 101057797, 100926470, 101124103, 84280580, 134743557,
168495113, 134679307, 117769737, 117967885, 100992517, 202902532,
101320709, 117967109, 122, 4093, 84084748, 134612487,
    168364556, 101124619, 84150284, 185009410, 50333974, 84150795,
117769734, 50596107, 168429317, 151456012, 117901067, 118229513, 123,
32756, 65532, 134612742, 151455497, 100926985,
    202641417, 151324166, 100992522, 101123847, 202181123, 50333710,
33818118, 84148996, 16974083, 100926723, 249, 32757, 16843266,
83951873, 67372295, 16909317, 33817858, 84148994,
    100992003, 67305730, 168100355, 67305990, 16909318, 50529284,
67437059, 33817859, 250, 65518, 134546436, 33882885, 67373831,
50464528, 84083460, 67437572, 50529285, 50462979, 84214788,
    117703172, 117900549, 50462724, 33817091, 67437570, 251, 65521,
151257608, 67372295, 67372036, 50660356, 33620483, 33883653, 84083972,
84345604, 50989314, 50595332, 67305987, 117637893,
    33620483, 50529283, 508, 65524, 33752068, 84083204, 84148997,
16975364, 84149251...},
  ehufsi = "\005\001\004\a\f\020\020\020\020\020\000\000\000\000\000\000\000\003\005\t\020\020\020\000\000\000\000\000\000\000\000\000\000\004\a\v\020",
'\000' <repeats 12 times>, "\004\b\r", '\000' <repeats 13 times>,
"\005\t\020", '\000' <repeats 13 times>, "\006\n\020", '\000' <repeats
13 times>, "\006\v\020", '\000' <repeats 13 times>, "\a\f", '\000'
<repeats 14 times>, "\a\017\020", '\000' <repeats 13 times>, "\b\017",
'\000' <repeats 14 times>, "\b\020", '\000' <repeats 14 times>,
"\b\020", '\000' <repeats 14 times>, "\t\020", '\000' <repeats 14
times>...}
(gdb) print *block
$20 = -591
(gdb) print state->cur.cinfo
There is no member named cinfo.
(gdb) print *(state->cur.cinfo)
There is no member named cinfo.
(gdb) print *(state->cinfo)
$21 = {err = 0x7fffffff4150, mem = 0x621550, progress = 0x0,
client_data = 0x7fffffff4200, is_decompressor = 0, global_state = 101,
dest = 0x63a040, image_width = 1944, image_height = 2592,
  input_components = 3, in_color_space = JCS_RGB, input_gamma = 1,
data_precision = 8, num_components = 3, jpeg_color_space = JCS_YCbCr,
comp_info = 0x61c450, quant_tbl_ptrs = {0x61c810,
    0x61c8a0, 0x0, 0x0}, dc_huff_tbl_ptrs = {0x61c930, 0x61cb70, 0x0,
0x0}, ac_huff_tbl_ptrs = {0x61ca50, 0x61cc90, 0x0, 0x0}, arith_dc_L =
'\000' <repeats 15 times>,
  arith_dc_U = '\001' <repeats 16 times>, arith_ac_K = '\005' <repeats
16 times>, num_scans = 1, scan_info = 0x0, raw_data_in = 0, arith_code
= 0, optimize_coding = 1, CCIR601_sampling = 0,
  smoothing_factor = 0, dct_method = JDCT_FLOAT, restart_interval = 0,
restart_in_rows = 0, write_JFIF_header = 1, JFIF_major_version = 1
'\001', JFIF_minor_version = 1 '\001',
  density_unit = 1 '\001', X_density = 72, Y_density = 72,
write_Adobe_marker = 0, next_scanline = 2592, progressive_mode = 0,
max_h_samp_factor = 2, max_v_samp_factor = 2,
  total_iMCU_rows = 162, comps_in_scan = 3, cur_comp_info = {0x61c450,
0x61c4b0, 0x61c510, 0x0}, MCUs_per_row = 122, MCU_rows_in_scan = 162,
blocks_in_MCU = 6, MCU_membership = {0, 0, 0, 0,
    1, 2, 0, 0, 0, 0}, Ss = 0, Se = 63, Ah = 0, Al = 0, master =
0x63a080, main = 0x63a6d0, prep = 0x63a140, coef = 0x63a430, marker =
0x63a840, cconvert = 0x63a0b0, downsample = 0x63a0d0,
  fdct = 0x63a1e0, entropy = 0x63a370, script_space = 0x0,
script_space_size = 0}


[1] https://securityblog.redhat.com/2013/10/23/debugging-stack-protector-failures/

>
>
> On 11/7/14 11:26 AM, roucaries bastien wrote:
>>
>> On Fri, Nov 7, 2014 at 4:57 PM, DRC <dcommander@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@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@entry=2,
>> fmt=fmt@entry=0x7ffff719568b "*** %s ***: %s terminated\n") at
>> ../sysdeps/posix/libc_fatal.c:175
>> #3  0x00007ffff7128137 in __GI___fortify_fail
>> (msg=msg@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@entry=0x604f90, command=0x400810
>> <ConvertImageCommand@plt>, argc=argc@entry=5,
>> argv=argv@entry=0x7fffffffe118,
>>      metadata=metadata@entry=0x0, exception=exception@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.
>>>
>

---

Message #52 received at 768369@bugs.debian.org (full text, mbox, reply):

I don't know why you would expect me to have tried that, given that 
there was no reasonable expectation that I would know any of that 
information prior to now.

But I did just try it, and it works fine.

I will re-iterate:
You need to produce a test case that demonstrates this failure using 
only libjpeg-turbo.  You cannot expect me to spend any time on this 
until it is proven that it is my bug and not someone else's.  Sometimes 
issues like this can be caused by the overlying application, even though 
the bug manifests in the underlying library.


On 11/7/14 12:47 PM, roucaries bastien wrote:
> On Fri, Nov 7, 2014 at 6:36 PM, DRC <dcommander@users.sourceforge.net> wrote:
>> 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.
>
> Did you try to compile libjpeg-turbo with -fstack-protector-all ggc
> flags. Debian do it and thus detect stack overflow (valgrind is not at
> help here).
>
> BTW could you nevertheless get a glimpse at the last backtrace. I but
> a watch point on the canary (I tried but because this function is
> called a lot of time I may be missing something) using method [1]. It
> seems the code that smash the code is at encode_one_block line 543:
>   kloop(59);  kloop(52);  kloop(45);  kloop(38);  kloop(31);  kloop(39);

---

Message #57 received at 768369@bugs.debian.org (full text, mbox, reply):

[Message part 1 (text/plain, inline)]

What works:

  convert 003632r270.jpg -rotate 270 junk.jpg

This works too with libjpeg-6b:

  convert -define jpeg:optimize-coding=true 003632r270.jpg -rotate 270
junk.jpg

The same command fails if we use libturbojpeg 1.3.1:

gdb convert
run -define jpeg:optimize-coding=true 003632r270.jpg -rotate 270 junk.jpg
*** stack smashing detected ***: /usr/local/bin/convert terminated
...
where
#0  0x0000003bb1035877 in raise () from /lib64/libc.so.6
#1  0x0000003bb1036f68 in abort () from /lib64/libc.so.6
#2  0x0000003bb1075a54 in __libc_message () from /lib64/libc.so.6
#3  0x0000003bb1106947 in __fortify_fail () from /lib64/libc.so.6
#4  0x0000003bb1106910 in __stack_chk_fail () from /lib64/libc.so.6
#5  0x00000000007c6b2b in encode_mcu_huff (cinfo=0x7fffffff83b0,
    MCU_data=0xc54110) at jchuff.c:641
#6  0x00000000007b9399 in compress_output (cinfo=0x7fffffff83b0,
    input_buf=<optimized out>) at jccoefct.c:381
#7  0x0000000000795426 in jpeg_finish_compress (
    cinfo=cinfo@entry=0x7fffffff83b0) at jcapimin.c:183
#8  0x00000000005741df in WriteJPEGImage (image_info=0xc4fb40,
image=0xc41b10)
    at coders/jpeg.c:2794
#9  0x00000000005de602 in WriteImage (image_info=image_info@entry=0xc06950,
    image=image@entry=0xc41b10) at magick/constitute.c:1114
...

To reproduce:

wget http://www.imagemagick.org/download/ImageMagick-6.8.9-10.tar.gz
tar xvf ImageMagick-6.8.9-10.tar.gz
cd ImageMagick-6.8.9-10
<download / unpack libjpeg-turbo>
mv libjpeg-turbo-1.3.1 jpeg
cd jpeg
export CFLAGS="-O3 -fPIC -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2
-fexceptions -fstack-protector"
./configure --disable-shared
make
cd ..
./configure --enable-delegate-build --disable-shared
make -j3
make install
gdb convert
run -define jpeg:optimize-coding=true 003632r270.jpg -rotate 270 junk.jpg
*** stack smashing detected ***: /usr/local/bin/convert terminated

Did ImageMagick corrupt the stack?  Possible, we're investigating, however,
its curious that the same command works for libjpeg-6b.  We did use
valgrind and valgrind did not reveal any memory corruption in ImageMagick.

Cristy
ImageMagick Principle Architect

[Message part 2 (text/html, inline)]

---

Message #62 received at 768369@bugs.debian.org (full text, mbox, reply):

We have investigated a little bit (thansk y dlemstra )

was able to reproduce the problem under Windows that uses libturbo
1.3.0. It looks like the problem is inside the STORE_BUFFER macro at
line 421 of jchuff.c:

Code: Select all

buffer = _buffer; \
while (bytes > 0) { \
  bytestocopy = min(bytes, state->free_in_buffer); \
  MEMCOPY(state->next_output_byte, buffer, bytestocopy); \
  state->next_output_byte += bytestocopy; \
  buffer += bytestocopy; \
  state->free_in_buffer -= bytestocopy; \
  if (state->free_in_buffer == 0) \
    if (! dump_buffer(state)) return FALSE; \
  bytes -= bytestocopy; \
} \


The size of _buffer is BUF_SIZE = (DCTSIZE2 * 2) = (64 * 2) = 128. The
following is happening at *block == -591:

1. bytes = 171, state->free_in_buffer = 14 and bytestocopy becomes 14
2. memcopy is called and the buffer is moved to index 14
4. state->free_in_buffer becomes 0, dump_buffer is called and returns true
5. bytes = 157, state->free_in_buffer = 16384 and bytestocopy becomes 157

(14 + 157) > 128 and this causes a buffer overflow.

Not sure why bytes becomes more then 128 but this info should probably
give the maintainers of libjpegturbo a bit more information to
investigate this issue.

On Fri, Nov 7, 2014 at 9:33 PM, DRC <dcommander@users.sourceforge.net> wrote:
> I don't know why you would expect me to have tried that, given that there
> was no reasonable expectation that I would know any of that information
> prior to now.
>
> But I did just try it, and it works fine.
>
> I will re-iterate:
> You need to produce a test case that demonstrates this failure using only
> libjpeg-turbo.  You cannot expect me to spend any time on this until it is
> proven that it is my bug and not someone else's.  Sometimes issues like this
> can be caused by the overlying application, even though the bug manifests in
> the underlying library.
>
>
>
> On 11/7/14 12:47 PM, roucaries bastien wrote:
>>
>> On Fri, Nov 7, 2014 at 6:36 PM, DRC <dcommander@users.sourceforge.net>
>> wrote:
>>>
>>> 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.
>>
>>
>> Did you try to compile libjpeg-turbo with -fstack-protector-all ggc
>> flags. Debian do it and thus detect stack overflow (valgrind is not at
>> help here).
>>
>> BTW could you nevertheless get a glimpse at the last backtrace. I but
>> a watch point on the canary (I tried but because this function is
>> called a lot of time I may be missing something) using method [1]. It
>> seems the code that smash the code is at encode_one_block line 543:
>>   kloop(59);  kloop(52);  kloop(45);  kloop(38);  kloop(31);  kloop(39);

---

Message #67 received at 768369@bugs.debian.org (full text, mbox, reply):

Have you tried libjpeg-turbo 1.4 beta? I believe this has already been fixed. Another user reported a very low-probability event (literally 1 in a million) that would cause the 128-byte buffer to be exceeded when encoding a JPEG image using quality 100. If you have a specific image that consistently reproduces this issue, please send it to me. Otherwise, please try the latest release. 1.3.0 is not even the latest release in the prior branch.

> On Nov 12, 2014, at 3:11 PM, roucaries bastien <roucaries.bastien+debian@gmail.com> wrote:
> 
> We have investigated a little bit (thansk y dlemstra )
> 
> was able to reproduce the problem under Windows that uses libturbo
> 1.3.0. It looks like the problem is inside the STORE_BUFFER macro at
> line 421 of jchuff.c:
> 
> Code: Select all
> 
> buffer = _buffer; \
> while (bytes > 0) { \
>  bytestocopy = min(bytes, state->free_in_buffer); \
>  MEMCOPY(state->next_output_byte, buffer, bytestocopy); \
>  state->next_output_byte += bytestocopy; \
>  buffer += bytestocopy; \
>  state->free_in_buffer -= bytestocopy; \
>  if (state->free_in_buffer == 0) \
>    if (! dump_buffer(state)) return FALSE; \
>  bytes -= bytestocopy; \
> } \
> 
> 
> The size of _buffer is BUF_SIZE = (DCTSIZE2 * 2) = (64 * 2) = 128. The
> following is happening at *block == -591:
> 
> 1. bytes = 171, state->free_in_buffer = 14 and bytestocopy becomes 14
> 2. memcopy is called and the buffer is moved to index 14
> 4. state->free_in_buffer becomes 0, dump_buffer is called and returns true
> 5. bytes = 157, state->free_in_buffer = 16384 and bytestocopy becomes 157
> 
> (14 + 157) > 128 and this causes a buffer overflow.
> 
> Not sure why bytes becomes more then 128 but this info should probably
> give the maintainers of libjpegturbo a bit more information to
> investigate this issue.
> 
>> On Fri, Nov 7, 2014 at 9:33 PM, DRC <dcommander@users.sourceforge.net> wrote:
>> I don't know why you would expect me to have tried that, given that there
>> was no reasonable expectation that I would know any of that information
>> prior to now.
>> 
>> But I did just try it, and it works fine.
>> 
>> I will re-iterate:
>> You need to produce a test case that demonstrates this failure using only
>> libjpeg-turbo.  You cannot expect me to spend any time on this until it is
>> proven that it is my bug and not someone else's.  Sometimes issues like this
>> can be caused by the overlying application, even though the bug manifests in
>> the underlying library.
>> 
>> 
>> 
>>> On 11/7/14 12:47 PM, roucaries bastien wrote:
>>> 
>>> On Fri, Nov 7, 2014 at 6:36 PM, DRC <dcommander@users.sourceforge.net>
>>> wrote:
>>>> 
>>>> 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.
>>> 
>>> 
>>> Did you try to compile libjpeg-turbo with -fstack-protector-all ggc
>>> flags. Debian do it and thus detect stack overflow (valgrind is not at
>>> help here).
>>> 
>>> BTW could you nevertheless get a glimpse at the last backtrace. I but
>>> a watch point on the canary (I tried but because this function is
>>> called a lot of time I may be missing something) using method [1]. It
>>> seems the code that smash the code is at encode_one_block line 543:
>>>  kloop(59);  kloop(52);  kloop(45);  kloop(38);  kloop(31);  kloop(39);

---

Message #72 received at 768369@bugs.debian.org (full text, mbox, reply):

[Message part 1 (text/plain, inline)]

Hello,
probably the attached patch could help in diagnose the issue.
It prints an error message and aborts, when the current buffer
pointer is advanced past the _buffer.

In debugger it shows this happens a little before what roucaries bastien in message 47 wrote.
(Because he stopped at the stack protector overwritten,
this is _buffer[137] while its size is only 128.)

Kind regards,
Bernhard




$ gdb --args convert -rotate 270 003632r270.jpg junk.jpg

(gdb) run

jchuff.c, line 591: written beyond end of _buffer, size=128, _buffer=0x0x7fffffff3e10, buffer=0x0x7fffffff3e91, pos=129

Program received signal SIGABRT, Aborted.

(gdb) bt
#0  0x00007ffff7067107 in __GI_raise (sig=sig@entry=6) at ../nptl/sysdeps/unix/sysv/linux/raise.c:56
#1  0x00007ffff70684e8 in __GI_abort () at abort.c:89
#2  0x00007ffff36d4268 in encode_one_block (actbl=0x646920, dctbl=<optimized out>, last_dc_val=<optimized out>, block=0x7ffff2cf9bb0, state=0x7fffffff3dd0) at jchuff.c:591

(gdb) up
(gdb) up
#2  0x00007ffff36d4268 in encode_one_block (actbl=0x646920, dctbl=<optimized out>, last_dc_val=<optimized out>, block=0x7ffff2cf9bb0, state=0x7fffffff3dd0) at jchuff.c:591
591       kloop(44);

[002_detect-buffer-overrun-in-jchuff_c.patch (text/x-patch, attachment)]

---

Message #77 received at 768369@bugs.debian.org (full text, mbox, reply):

[Message part 1 (text/plain, inline)]

Hello,
DRC suggested to have a look at the newer upstream version.

In jchuff.c the buffer in question is there really grown.
But only by 8 bytes. [1]

When increasing by 28 bytes the stack smashing and writing beyond the
buffer goes away.

The resulting image "looks" good. (Input file from the first post.)

If this is the right solution or if the buffer can grow even more I
cannot say.

Kind regards,
Bernhard

[1] http://sourceforge.net/p/libjpeg-turbo/code/1367/ and
    http://sourceforge.net/p/libjpeg-turbo/code/1364/




On Sat, 15 Nov 2014 16:56:20 +0100
=?UTF-8?B?QmVybmhhcmQgw5xiZWxhY2tlcg==?= <bernhardu@vr-web.de> wrote:
> Hello,
> probably the attached patch could help in diagnose the issue.
> It prints an error message and aborts, when the current buffer
> pointer is advanced past the _buffer.
> 
> In debugger it shows this happens a little before what roucaries bastien in message 47 wrote.
> (Because he stopped at the stack protector overwritten,
> this is _buffer[137] while its size is only 128.)
> 
> Kind regards,
> Bernhard
> 
> 
> 
> 
> $ gdb --args convert -rotate 270 003632r270.jpg junk.jpg
> 
> (gdb) run
> 
> jchuff.c, line 591: written beyond end of _buffer, size=128, _buffer=0x0x7fffffff3e10, buffer=0x0x7fffffff3e91, pos=129
> 
> Program received signal SIGABRT, Aborted.
> 
> (gdb) bt
> #0  0x00007ffff7067107 in __GI_raise (sig=sig@entry=6) at ../nptl/sysdeps/unix/sysv/linux/raise.c:56
> #1  0x00007ffff70684e8 in __GI_abort () at abort.c:89
> #2  0x00007ffff36d4268 in encode_one_block (actbl=0x646920, dctbl=<optimized out>, last_dc_val=<optimized out>, block=0x7ffff2cf9bb0, state=0x7fffffff3dd0) at jchuff.c:591
> 
> (gdb) up
> (gdb) up
> #2  0x00007ffff36d4268 in encode_one_block (actbl=0x646920, dctbl=<optimized out>, last_dc_val=<optimized out>, block=0x7ffff2cf9bb0, state=0x7fffffff3dd0) at jchuff.c:591
> 591       kloop(44);
> 
> 
> 

[003_increase-size-of-local-buffer-in-jchuff_c.patch (text/x-patch, attachment)]

---

Message #82 received at 768369@bugs.debian.org (full text, mbox, reply):

Control: severity -1 important

Lowering the severity until the bug is confirmed.

Cheers,
-- 
Ondřej Surý <ondrej@sury.org>
Knot DNS (https://www.knot-dns.cz/) – a high-performance DNS server
-- 
Ondřej Surý <ondrej@sury.org>
Knot DNS (https://www.knot-dns.cz/) – a high-performance DNS server

---

Message #89 received at 768369@bugs.debian.org (full text, mbox, reply):

Hi,

For me it is a serious bug.

According to http://sourceforge.net/p/libjpeg-turbo/bugs/64/?page=1
(see http://sourceforge.net/p/libjpeg-turbo/bugs/64/?page=1):

>Even though I'm doing the most I can to stack the deck in favor of the bug, it still only occurs once in about every 25 million iterations.
>I have checked in your patch without modifications.
>
>So far, 130 bytes is the maximum I have been able to produce for a single MCU using the test, after literally a billion iterations. However, I am running it overnight so I can collect as many cases of >degenerate input images as I can, so I can hopefully determine what the upper bound is for the local buffer.

Thus I am tented to add it is a true bug.

Bastien

---

Message #94 received at 768369@bugs.debian.org (full text, mbox, reply):

Bastien,

don't get me wrong. I think this is "serious" bug, but not with severity
"serious"[1] as this needs the user to do an explicit operation to
trigger the bug.

1. see https://www.debian.org/Bugs/Developer#severities:

Cheers,
Ondrej

On Mon, Nov 17, 2014, at 21:21, Bastien ROUCARIES wrote:
> Hi,
> 
> For me it is a serious bug.
> 
> According to http://sourceforge.net/p/libjpeg-turbo/bugs/64/?page=1
> (see http://sourceforge.net/p/libjpeg-turbo/bugs/64/?page=1):
> 
> >Even though I'm doing the most I can to stack the deck in favor of the bug, it still only occurs once in about every 25 million iterations.
> >I have checked in your patch without modifications.
> >
> >So far, 130 bytes is the maximum I have been able to produce for a single MCU using the test, after literally a billion iterations. However, I am running it overnight so I can collect as many cases of >degenerate input images as I can, so I can hopefully determine what the upper bound is for the local buffer.
> 
> Thus I am tented to add it is a true bug.
> 
> Bastien


-- 
Ondřej Surý <ondrej@sury.org>
Knot DNS (https://www.knot-dns.cz/) – a high-performance DNS server

---

Message #99 received at 768369@bugs.debian.org (full text, mbox, reply):

[Message part 1 (text/plain, inline)]

Le 18 nov. 2014 06:30, "Ondřej Surý" <ondrej@sury.org> a écrit :
>
> Bastien,
>
> don't get me wrong. I think this is "serious" bug, but not with severity
> "serious"[1] as this needs the user to do an explicit operation to
> trigger the bug.

It could be trigerred by imagick remotly.

Bastien
>
> 1. see https://www.debian.org/Bugs/Developer#severities:
>
> Cheers,
> Ondrej
>
> On Mon, Nov 17, 2014, at 21:21, Bastien ROUCARIES wrote:
> > Hi,
> >
> > For me it is a serious bug.
> >
> > According to http://sourceforge.net/p/libjpeg-turbo/bugs/64/?page=1
> > (see http://sourceforge.net/p/libjpeg-turbo/bugs/64/?page=1):
> >
> > >Even though I'm doing the most I can to stack the deck in favor of the
bug, it still only occurs once in about every 25 million iterations.
> > >I have checked in your patch without modifications.
> > >
> > >So far, 130 bytes is the maximum I have been able to produce for a
single MCU using the test, after literally a billion iterations. However, I
am running it overnight so I can collect as many cases of >degenerate input
images as I can, so I can hopefully determine what the upper bound is for
the local buffer.
> >
> > Thus I am tented to add it is a true bug.
> >
> > Bastien
>
>
> --
> Ondřej Surý <ondrej@sury.org>
> Knot DNS (https://www.knot-dns.cz/) – a high-performance DNS server

[Message part 2 (text/html, inline)]

---

Message #104 received at 768369@bugs.debian.org (full text, mbox, reply):

[Message part 1 (text/plain, inline)]

On Tue, Nov 18, 2014, at 07:39, Bastien ROUCARIES wrote:
>
>
Le 18 nov. 2014 06:30, "Ondřej Surý" <ondrej@sury.org> a écrit :
>
>
>
> Bastien,
>
>
>
> don't get me wrong. I think this is "serious" bug, but not with
> severity
>
> "serious"[1] as this needs the user to do an explicit operation to
>
> trigger the bug.

> It could be trigerred by imagick remotly.


How? All reports I have seen required the user to take explicit action
on a strange image.

Anyway I will update the package as soon as there's an upstream fix.
(Update to 1.4.0rc is not "the fix").

Cheers,
--
Ondřej Surý <ondrej@sury.org> Knot DNS (https://www.knot-dns.cz/) – a
high-performance DNS server

[Message part 2 (text/html, inline)]

---

Message #109 received at 768369@bugs.debian.org (full text, mbox, reply):

[Message part 1 (text/plain, inline)]

Hi, guys.  So what's still tripping me up on this is that I can't 
reproduce it using only libjpeg-turbo.  There is really no action I can 
take until I am able to do that, because without the ability to 
reproduce the issue irrespective of ImageMagick, I have no way of 
knowing whether this is truly a bug in libjpeg-turbo or whether it is 
caused by ImageMagick doing something wrong and producing undefined 
behavior.  It would be helpful if someone could point me to the specific 
code in ImageMagick that is causing the failure.  Assume I have no time 
to spend on this, so me building ImageMagick from source is probably not 
going to happen anytime soon.  Our best hope of fixing this is if 
someone can help me isolate it and write a simple test program to 
reproduce it outside of ImageMagick.

libjpeg-turbo's Huffman code was studied very carefully in recent 
months, in the process of fixing this issue:
https://sourceforge.net/p/libjpeg-turbo/bugs/64

Specifically, take a look at this comment:
https://sourceforge.net/p/libjpeg-turbo/bugs/64/?limit=10&page=1#3aa9

which includes a test program that was used to reproduce the overrun. 
130 bytes (2-byte overrun) was the maximum I could reproduce, even using 
absolute worst-case artificially-constructed circumstances that will 
never happen in real life.  Even then, the issue occurred only a few 
times out of literally a billion iterations, and after increasing the 
local buffer size by 8 bytes, the original submitter of the bug report 
has had no issues since then (and his software apparently hits the 
compressor 200 million times a day.)  That's why I increased the local 
buffer size by 8 bytes.  I don't have a problem with increasing it more, 
but I need to understand what's happening first.

One thing that is important to note is that the Huffman local buffer is 
only ever used if the memory destination manager is used.  Thus, I 
modified jpegtran using mozjpeg's patches (attached) that allow it to 
use the memory destination manager.  This was an attempt to simulate 
what I thought ImageMagick might be doing, but it unfortunately didn't 
reproduce the bug when I ran 'jpegtran -rotate 270 003632r270.jpg 
>junk.jpg'.  Note also that I am including 
002_detect-buffer-overrun-in-jchuff_c.patch from above, which should 
print an error if the Huffman local buffer is overrun.  At this point, 
I'm stymied.  If someone can point me to the place in the ImageMagick 
code where this is happening, I can at least take a look at how they're 
calling the transformer and see how it differs from how I'm calling the 
transformer.


On 11/15/14 10:51 AM, Bernhard Übelacker wrote:
> Hello,
> DRC suggested to have a look at the newer upstream version.
>
> In jchuff.c the buffer in question is there really grown.
> But only by 8 bytes. [1]
>
> When increasing by 28 bytes the stack smashing and writing beyond the
> buffer goes away.
>
> The resulting image "looks" good. (Input file from the first post.)
>
> If this is the right solution or if the buffer can grow even more I
> cannot say.
>
> Kind regards,
> Bernhard
>
> [1] http://sourceforge.net/p/libjpeg-turbo/code/1367/ and
>      http://sourceforge.net/p/libjpeg-turbo/code/1364/
>
>
>
>
> On Sat, 15 Nov 2014 16:56:20 +0100
> =?UTF-8?B?QmVybmhhcmQgw5xiZWxhY2tlcg==?= <bernhardu@vr-web.de> wrote:
>> Hello,
>> probably the attached patch could help in diagnose the issue.
>> It prints an error message and aborts, when the current buffer
>> pointer is advanced past the _buffer.
>>
>> In debugger it shows this happens a little before what roucaries bastien in message 47 wrote.
>> (Because he stopped at the stack protector overwritten,
>> this is _buffer[137] while its size is only 128.)
>>
>> Kind regards,
>> Bernhard
>>
>>
>>
>>
>> $ gdb --args convert -rotate 270 003632r270.jpg junk.jpg
>>
>> (gdb) run
>>
>> jchuff.c, line 591: written beyond end of _buffer, size=128, _buffer=0x0x7fffffff3e10, buffer=0x0x7fffffff3e91, pos=129
>>
>> Program received signal SIGABRT, Aborted.
>>
>> (gdb) bt
>> #0  0x00007ffff7067107 in __GI_raise (sig=sig@entry=6) at ../nptl/sysdeps/unix/sysv/linux/raise.c:56
>> #1  0x00007ffff70684e8 in __GI_abort () at abort.c:89
>> #2  0x00007ffff36d4268 in encode_one_block (actbl=0x646920, dctbl=<optimized out>, last_dc_val=<optimized out>, block=0x7ffff2cf9bb0, state=0x7fffffff3dd0) at jchuff.c:591
>>
>> (gdb) up
>> (gdb) up
>> #2  0x00007ffff36d4268 in encode_one_block (actbl=0x646920, dctbl=<optimized out>, last_dc_val=<optimized out>, block=0x7ffff2cf9bb0, state=0x7fffffff3dd0) at jchuff.c:591
>> 591       kloop(44);
>>
>>
>>

[0001-jpegtran-use-mem-srcdst.patch (text/plain, attachment)]

---

Message #114 received at 768369@bugs.debian.org (full text, mbox, reply):

[Message part 1 (text/plain, inline)]

Hello,
I created a minimal test case in around 200 lines.

It uses a file with the intercepted scanlines of the calls to jpeg_write_scanlines.

Also the Exif marker is read from such a file.
(And without this Exif marker the stack smash does not happen...)

The partial output file is byte equal to that generated by imagemagick before it crashes.

The number of calls to encode_mcu_huff and the stack seem also to be the same.

Kind regards,
Bernhard



Place all three files in the same directory and open a shell there:
(I just created the breakpoint to see how often it is called.)


$ bunzip2 jpeg_write_marker.bin.bz2
$ bunzip2 jpeg_write_scanlines.bin.bz2
$ gcc -g -O0 -fstack-protector-all test-768369.c -ljpeg
$ gdb --args ./a.out
...
(gdb) b encode_mcu_huff
Breakpoint 1 (encode_mcu_huff) pending.
(gdb) ignore 1 10000
Will ignore next 10000 crossings of breakpoint 1.
(gdb) run
Starting program: /home/bernhard/data/entwicklung/2014/debian/libjpegturbo/a.out 
*** stack smashing detected ***: /home/bernhard/data/entwicklung/2014/debian/libjpegturbo/a.out terminated
...
(gdb) info break
Num     Type           Disp Enb Address            What
1       breakpoint     keep y   0x00007ffff7b8c190 in encode_mcu_huff at jchuff.c:593
        breakpoint already hit 9842 times
        ignore next 158 hits

(gdb) bt
#0  0x00007ffff7811107 in __GI_raise (sig=sig@entry=6) at ../nptl/sysdeps/unix/sysv/linux/raise.c:56
#1  0x00007ffff78124e8 in __GI_abort () at abort.c:89
#2  0x00007ffff784f044 in __libc_message (do_abort=do_abort@entry=2, fmt=fmt@entry=0x7ffff793f6ab "*** %s ***: %s terminated\n") at ../sysdeps/posix/libc_fatal.c:175
#3  0x00007ffff78d2147 in __GI___fortify_fail (msg=msg@entry=0x7ffff793f693 "stack smashing detected") at fortify_fail.c:31
#4  0x00007ffff78d2110 in __stack_chk_fail () at stack_chk_fail.c:28
#5  0x00007ffff7b96553 in encode_mcu_huff (cinfo=0x7fffffffdd70, MCU_data=0x602720) at jchuff.c:641
#6  0x00007ffff7b89717 in compress_output (cinfo=0x7fffffffdd70, input_buf=<optimized out>) at jccoefct.c:381
#7  0x00007ffff7b89006 in jpeg_finish_compress (cinfo=0x7fffffffdd70) at jcapimin.c:183
#8  0x0000000000401196 in main () at test-768369.c:205

[jpeg_write_marker.bin.bz2 (application/x-bzip, attachment)]

[jpeg_write_scanlines.bin.bz2 (application/x-bzip, attachment)]

[test-768369.c (text/x-csrc, attachment)]

---

Message #119 received at 768369@bugs.debian.org (full text, mbox, reply):

control: tags -1 + confirmed
control: severity - 1 serious
justification: does not need imagemagick

On Sat, Nov 22, 2014 at 7:43 AM, Bernhard Übelacker <bernhardu@vr-web.de> wrote:
> Hello,
> I created a minimal test case in around 200 lines.
>
> It uses a file with the intercepted scanlines of the calls to jpeg_write_scanlines.
>
> Also the Exif marker is read from such a file.
> (And without this Exif marker the stack smash does not happen...)
>
> The partial output file is byte equal to that generated by imagemagick before it crashes.
>
> The number of calls to encode_mcu_huff and the stack seem also to be the same.
>
> Kind regards,
> Bernhard
>
>
>
> Place all three files in the same directory and open a shell there:
> (I just created the breakpoint to see how often it is called.)
>
>
> $ bunzip2 jpeg_write_marker.bin.bz2
> $ bunzip2 jpeg_write_scanlines.bin.bz2
> $ gcc -g -O0 -fstack-protector-all test-768369.c -ljpeg
> $ gdb --args ./a.out
> ...
> (gdb) b encode_mcu_huff
> Breakpoint 1 (encode_mcu_huff) pending.
> (gdb) ignore 1 10000
> Will ignore next 10000 crossings of breakpoint 1.
> (gdb) run
> Starting program: /home/bernhard/data/entwicklung/2014/debian/libjpegturbo/a.out
> *** stack smashing detected ***: /home/bernhard/data/entwicklung/2014/debian/libjpegturbo/a.out terminated
> ...
> (gdb) info break
> Num     Type           Disp Enb Address            What
> 1       breakpoint     keep y   0x00007ffff7b8c190 in encode_mcu_huff at jchuff.c:593
>         breakpoint already hit 9842 times
>         ignore next 158 hits
>
> (gdb) bt
> #0  0x00007ffff7811107 in __GI_raise (sig=sig@entry=6) at ../nptl/sysdeps/unix/sysv/linux/raise.c:56
> #1  0x00007ffff78124e8 in __GI_abort () at abort.c:89
> #2  0x00007ffff784f044 in __libc_message (do_abort=do_abort@entry=2, fmt=fmt@entry=0x7ffff793f6ab "*** %s ***: %s terminated\n") at ../sysdeps/posix/libc_fatal.c:175
> #3  0x00007ffff78d2147 in __GI___fortify_fail (msg=msg@entry=0x7ffff793f693 "stack smashing detected") at fortify_fail.c:31
> #4  0x00007ffff78d2110 in __stack_chk_fail () at stack_chk_fail.c:28
> #5  0x00007ffff7b96553 in encode_mcu_huff (cinfo=0x7fffffffdd70, MCU_data=0x602720) at jchuff.c:641
> #6  0x00007ffff7b89717 in compress_output (cinfo=0x7fffffffdd70, input_buf=<optimized out>) at jccoefct.c:381
> #7  0x00007ffff7b89006 in jpeg_finish_compress (cinfo=0x7fffffffdd70) at jcapimin.c:183
> #8  0x0000000000401196 in main () at test-768369.c:205
>
>
>
>

---

Message #128 received at 768369@bugs.debian.org (full text, mbox, reply):

I can readily reproduce the failure with the supplied test case, but 
what I'm tripping on right now is understanding why a Huffman-encoded 
block can grow so much larger than the size of the source block (128 
bytes.)  While this test case is very unusual, there may be others out 
there, and I want to understand what the worst case is for Huffman 
encoding.  That would determine the appropriate value for BUFSIZE. 
Generally speaking, libjpeg-turbo will only need to use the local 
Huffman buffer when the buffer supplied in the destination manager is 
nearly exhausted-- that is, when libjpeg-turbo feels like the size of 
the encoded Huffman data for a given block would overrun the destination 
manager's buffer.  But we don't want to make the local Huffman buffer 
too big, else it might affect performance (since it introduces an extra 
memcpy() for all of the bytes that are encoded into the local buffer.) 
Hence the desire to understand exactly how big a Huffman-encoded block 
can grow in theory.


On 11/22/14 12:43 AM, Bernhard Übelacker wrote:
> Hello,
> I created a minimal test case in around 200 lines.
>
> It uses a file with the intercepted scanlines of the calls to jpeg_write_scanlines.
>
> Also the Exif marker is read from such a file.
> (And without this Exif marker the stack smash does not happen...)
>
> The partial output file is byte equal to that generated by imagemagick before it crashes.
>
> The number of calls to encode_mcu_huff and the stack seem also to be the same.
>
> Kind regards,
> Bernhard
>
>
>
> Place all three files in the same directory and open a shell there:
> (I just created the breakpoint to see how often it is called.)
>
>
> $ bunzip2 jpeg_write_marker.bin.bz2
> $ bunzip2 jpeg_write_scanlines.bin.bz2
> $ gcc -g -O0 -fstack-protector-all test-768369.c -ljpeg
> $ gdb --args ./a.out
> ...
> (gdb) b encode_mcu_huff
> Breakpoint 1 (encode_mcu_huff) pending.
> (gdb) ignore 1 10000
> Will ignore next 10000 crossings of breakpoint 1.
> (gdb) run
> Starting program: /home/bernhard/data/entwicklung/2014/debian/libjpegturbo/a.out
> *** stack smashing detected ***: /home/bernhard/data/entwicklung/2014/debian/libjpegturbo/a.out terminated
> ...
> (gdb) info break
> Num     Type           Disp Enb Address            What
> 1       breakpoint     keep y   0x00007ffff7b8c190 in encode_mcu_huff at jchuff.c:593
>          breakpoint already hit 9842 times
>          ignore next 158 hits
>
> (gdb) bt
> #0  0x00007ffff7811107 in __GI_raise (sig=sig@entry=6) at ../nptl/sysdeps/unix/sysv/linux/raise.c:56
> #1  0x00007ffff78124e8 in __GI_abort () at abort.c:89
> #2  0x00007ffff784f044 in __libc_message (do_abort=do_abort@entry=2, fmt=fmt@entry=0x7ffff793f6ab "*** %s ***: %s terminated\n") at ../sysdeps/posix/libc_fatal.c:175
> #3  0x00007ffff78d2147 in __GI___fortify_fail (msg=msg@entry=0x7ffff793f693 "stack smashing detected") at fortify_fail.c:31
> #4  0x00007ffff78d2110 in __stack_chk_fail () at stack_chk_fail.c:28
> #5  0x00007ffff7b96553 in encode_mcu_huff (cinfo=0x7fffffffdd70, MCU_data=0x602720) at jchuff.c:641
> #6  0x00007ffff7b89717 in compress_output (cinfo=0x7fffffffdd70, input_buf=<optimized out>) at jccoefct.c:381
> #7  0x00007ffff7b89006 in jpeg_finish_compress (cinfo=0x7fffffffdd70) at jcapimin.c:183
> #8  0x0000000000401196 in main () at test-768369.c:205
>
>
>
>

---

Message #133 received at 768369@bugs.debian.org (full text, mbox, reply):

On Sat, Nov 22, 2014 at 6:58 PM, DRC <dcommander@users.sourceforge.net> wrote:
> I can readily reproduce the failure with the supplied test case, but what
> I'm tripping on right now is understanding why a Huffman-encoded block can
> grow so much larger than the size of the source block (128 bytes.)  While
> this test case is very unusual, there may be others out there, and I want to
> understand what the worst case is for Huffman encoding.  That would
> determine the appropriate value for BUFSIZE. Generally speaking,
> libjpeg-turbo will only need to use the local Huffman buffer when the buffer
> supplied in the destination manager is nearly exhausted-- that is, when
> libjpeg-turbo feels like the size of the encoded Huffman data for a given
> block would overrun the destination manager's buffer.  But we don't want to
> make the local Huffman buffer too big, else it might affect performance
> (since it introduces an extra memcpy() for all of the bytes that are encoded
> into the local buffer.) Hence the desire to understand exactly how big a
> Huffman-encoded block can grow in theory.

Could you exactly describe that you are doing (mathematically) ?

Bastien

>
>
> On 11/22/14 12:43 AM, Bernhard Übelacker wrote:
>>
>> Hello,
>> I created a minimal test case in around 200 lines.
>>
>> It uses a file with the intercepted scanlines of the calls to
>> jpeg_write_scanlines.
>>
>> Also the Exif marker is read from such a file.
>> (And without this Exif marker the stack smash does not happen...)
>>
>> The partial output file is byte equal to that generated by imagemagick
>> before it crashes.
>>
>> The number of calls to encode_mcu_huff and the stack seem also to be the
>> same.
>>
>> Kind regards,
>> Bernhard
>>
>>
>>
>> Place all three files in the same directory and open a shell there:
>> (I just created the breakpoint to see how often it is called.)
>>
>>
>> $ bunzip2 jpeg_write_marker.bin.bz2
>> $ bunzip2 jpeg_write_scanlines.bin.bz2
>> $ gcc -g -O0 -fstack-protector-all test-768369.c -ljpeg
>> $ gdb --args ./a.out
>> ...
>> (gdb) b encode_mcu_huff
>> Breakpoint 1 (encode_mcu_huff) pending.
>> (gdb) ignore 1 10000
>> Will ignore next 10000 crossings of breakpoint 1.
>> (gdb) run
>> Starting program:
>> /home/bernhard/data/entwicklung/2014/debian/libjpegturbo/a.out
>> *** stack smashing detected ***:
>> /home/bernhard/data/entwicklung/2014/debian/libjpegturbo/a.out terminated
>> ...
>> (gdb) info break
>> Num     Type           Disp Enb Address            What
>> 1       breakpoint     keep y   0x00007ffff7b8c190 in encode_mcu_huff at
>> jchuff.c:593
>>          breakpoint already hit 9842 times
>>          ignore next 158 hits
>>
>> (gdb) bt
>> #0  0x00007ffff7811107 in __GI_raise (sig=sig@entry=6) at
>> ../nptl/sysdeps/unix/sysv/linux/raise.c:56
>> #1  0x00007ffff78124e8 in __GI_abort () at abort.c:89
>> #2  0x00007ffff784f044 in __libc_message (do_abort=do_abort@entry=2,
>> fmt=fmt@entry=0x7ffff793f6ab "*** %s ***: %s terminated\n") at
>> ../sysdeps/posix/libc_fatal.c:175
>> #3  0x00007ffff78d2147 in __GI___fortify_fail
>> (msg=msg@entry=0x7ffff793f693 "stack smashing detected") at
>> fortify_fail.c:31
>> #4  0x00007ffff78d2110 in __stack_chk_fail () at stack_chk_fail.c:28
>> #5  0x00007ffff7b96553 in encode_mcu_huff (cinfo=0x7fffffffdd70,
>> MCU_data=0x602720) at jchuff.c:641
>> #6  0x00007ffff7b89717 in compress_output (cinfo=0x7fffffffdd70,
>> input_buf=<optimized out>) at jccoefct.c:381
>> #7  0x00007ffff7b89006 in jpeg_finish_compress (cinfo=0x7fffffffdd70) at
>> jcapimin.c:183
>> #8  0x0000000000401196 in main () at test-768369.c:205
>>
>>
>>
>>
>

---

Message #138 received at 768369@bugs.debian.org (full text, mbox, reply):

Never mind.  I think I answered my own question.  Although I don't 
understand the Huffman algorithm well enough to know whether this is 
algorithmically possible, a naive analysis of the code shows that it 
calls PUT_BITS 128 times for each block, and the "size" argument in all 
of those cases can theoretically be as high as 16.  So it seems to me 
that 2048 bits = 256 bytes (twice the size of the unencoded block) is 
the worst-case size for the Huffman-encoded block.  Thus, 256 seems like 
the best value for BUFSIZE, to be 100% sure that this sort of thing 
cannot possibly happen again in the future.


On 11/22/14 2:06 PM, roucaries bastien wrote:
> On Sat, Nov 22, 2014 at 6:58 PM, DRC <dcommander@users.sourceforge.net> wrote:
>> I can readily reproduce the failure with the supplied test case, but what
>> I'm tripping on right now is understanding why a Huffman-encoded block can
>> grow so much larger than the size of the source block (128 bytes.)  While
>> this test case is very unusual, there may be others out there, and I want to
>> understand what the worst case is for Huffman encoding.  That would
>> determine the appropriate value for BUFSIZE. Generally speaking,
>> libjpeg-turbo will only need to use the local Huffman buffer when the buffer
>> supplied in the destination manager is nearly exhausted-- that is, when
>> libjpeg-turbo feels like the size of the encoded Huffman data for a given
>> block would overrun the destination manager's buffer.  But we don't want to
>> make the local Huffman buffer too big, else it might affect performance
>> (since it introduces an extra memcpy() for all of the bytes that are encoded
>> into the local buffer.) Hence the desire to understand exactly how big a
>> Huffman-encoded block can grow in theory.
>
> Could you exactly describe that you are doing (mathematically) ?
>
> Bastien
>
>>
>>
>> On 11/22/14 12:43 AM, Bernhard Übelacker wrote:
>>>
>>> Hello,
>>> I created a minimal test case in around 200 lines.
>>>
>>> It uses a file with the intercepted scanlines of the calls to
>>> jpeg_write_scanlines.
>>>
>>> Also the Exif marker is read from such a file.
>>> (And without this Exif marker the stack smash does not happen...)
>>>
>>> The partial output file is byte equal to that generated by imagemagick
>>> before it crashes.
>>>
>>> The number of calls to encode_mcu_huff and the stack seem also to be the
>>> same.
>>>
>>> Kind regards,
>>> Bernhard
>>>
>>>
>>>
>>> Place all three files in the same directory and open a shell there:
>>> (I just created the breakpoint to see how often it is called.)
>>>
>>>
>>> $ bunzip2 jpeg_write_marker.bin.bz2
>>> $ bunzip2 jpeg_write_scanlines.bin.bz2
>>> $ gcc -g -O0 -fstack-protector-all test-768369.c -ljpeg
>>> $ gdb --args ./a.out
>>> ...
>>> (gdb) b encode_mcu_huff
>>> Breakpoint 1 (encode_mcu_huff) pending.
>>> (gdb) ignore 1 10000
>>> Will ignore next 10000 crossings of breakpoint 1.
>>> (gdb) run
>>> Starting program:
>>> /home/bernhard/data/entwicklung/2014/debian/libjpegturbo/a.out
>>> *** stack smashing detected ***:
>>> /home/bernhard/data/entwicklung/2014/debian/libjpegturbo/a.out terminated
>>> ...
>>> (gdb) info break
>>> Num     Type           Disp Enb Address            What
>>> 1       breakpoint     keep y   0x00007ffff7b8c190 in encode_mcu_huff at
>>> jchuff.c:593
>>>           breakpoint already hit 9842 times
>>>           ignore next 158 hits
>>>
>>> (gdb) bt
>>> #0  0x00007ffff7811107 in __GI_raise (sig=sig@entry=6) at
>>> ../nptl/sysdeps/unix/sysv/linux/raise.c:56
>>> #1  0x00007ffff78124e8 in __GI_abort () at abort.c:89
>>> #2  0x00007ffff784f044 in __libc_message (do_abort=do_abort@entry=2,
>>> fmt=fmt@entry=0x7ffff793f6ab "*** %s ***: %s terminated\n") at
>>> ../sysdeps/posix/libc_fatal.c:175
>>> #3  0x00007ffff78d2147 in __GI___fortify_fail
>>> (msg=msg@entry=0x7ffff793f693 "stack smashing detected") at
>>> fortify_fail.c:31
>>> #4  0x00007ffff78d2110 in __stack_chk_fail () at stack_chk_fail.c:28
>>> #5  0x00007ffff7b96553 in encode_mcu_huff (cinfo=0x7fffffffdd70,
>>> MCU_data=0x602720) at jchuff.c:641
>>> #6  0x00007ffff7b89717 in compress_output (cinfo=0x7fffffffdd70,
>>> input_buf=<optimized out>) at jccoefct.c:381
>>> #7  0x00007ffff7b89006 in jpeg_finish_compress (cinfo=0x7fffffffdd70) at
>>> jcapimin.c:183
>>> #8  0x0000000000401196 in main () at test-768369.c:205
>>>
>>>
>>>
>>>
>>

---

Message #143 received at 768369@bugs.debian.org (full text, mbox, reply):

I find that by setting the AC coefficients to alternating values of 
32767 and -32768 in the JPEG scanning order (1, 8, 16, 9, 2, 3, etc.), I 
can make the Huffman encoder exceed 200 bytes/block every single time. 
So that further confirms that 256 is the worst case.  I've checked in an 
upstream patch to subversion trunk, as well as branches/1.4.x and 
branches/1.3.x.


On 11/22/14 2:06 PM, roucaries bastien wrote:
> On Sat, Nov 22, 2014 at 6:58 PM, DRC <dcommander@users.sourceforge.net> wrote:
>> I can readily reproduce the failure with the supplied test case, but what
>> I'm tripping on right now is understanding why a Huffman-encoded block can
>> grow so much larger than the size of the source block (128 bytes.)  While
>> this test case is very unusual, there may be others out there, and I want to
>> understand what the worst case is for Huffman encoding.  That would
>> determine the appropriate value for BUFSIZE. Generally speaking,
>> libjpeg-turbo will only need to use the local Huffman buffer when the buffer
>> supplied in the destination manager is nearly exhausted-- that is, when
>> libjpeg-turbo feels like the size of the encoded Huffman data for a given
>> block would overrun the destination manager's buffer.  But we don't want to
>> make the local Huffman buffer too big, else it might affect performance
>> (since it introduces an extra memcpy() for all of the bytes that are encoded
>> into the local buffer.) Hence the desire to understand exactly how big a
>> Huffman-encoded block can grow in theory.
>
> Could you exactly describe that you are doing (mathematically) ?
>
> Bastien
>
>>
>>
>> On 11/22/14 12:43 AM, Bernhard Übelacker wrote:
>>>
>>> Hello,
>>> I created a minimal test case in around 200 lines.
>>>
>>> It uses a file with the intercepted scanlines of the calls to
>>> jpeg_write_scanlines.
>>>
>>> Also the Exif marker is read from such a file.
>>> (And without this Exif marker the stack smash does not happen...)
>>>
>>> The partial output file is byte equal to that generated by imagemagick
>>> before it crashes.
>>>
>>> The number of calls to encode_mcu_huff and the stack seem also to be the
>>> same.
>>>
>>> Kind regards,
>>> Bernhard
>>>
>>>
>>>
>>> Place all three files in the same directory and open a shell there:
>>> (I just created the breakpoint to see how often it is called.)
>>>
>>>
>>> $ bunzip2 jpeg_write_marker.bin.bz2
>>> $ bunzip2 jpeg_write_scanlines.bin.bz2
>>> $ gcc -g -O0 -fstack-protector-all test-768369.c -ljpeg
>>> $ gdb --args ./a.out
>>> ...
>>> (gdb) b encode_mcu_huff
>>> Breakpoint 1 (encode_mcu_huff) pending.
>>> (gdb) ignore 1 10000
>>> Will ignore next 10000 crossings of breakpoint 1.
>>> (gdb) run
>>> Starting program:
>>> /home/bernhard/data/entwicklung/2014/debian/libjpegturbo/a.out
>>> *** stack smashing detected ***:
>>> /home/bernhard/data/entwicklung/2014/debian/libjpegturbo/a.out terminated
>>> ...
>>> (gdb) info break
>>> Num     Type           Disp Enb Address            What
>>> 1       breakpoint     keep y   0x00007ffff7b8c190 in encode_mcu_huff at
>>> jchuff.c:593
>>>           breakpoint already hit 9842 times
>>>           ignore next 158 hits
>>>
>>> (gdb) bt
>>> #0  0x00007ffff7811107 in __GI_raise (sig=sig@entry=6) at
>>> ../nptl/sysdeps/unix/sysv/linux/raise.c:56
>>> #1  0x00007ffff78124e8 in __GI_abort () at abort.c:89
>>> #2  0x00007ffff784f044 in __libc_message (do_abort=do_abort@entry=2,
>>> fmt=fmt@entry=0x7ffff793f6ab "*** %s ***: %s terminated\n") at
>>> ../sysdeps/posix/libc_fatal.c:175
>>> #3  0x00007ffff78d2147 in __GI___fortify_fail
>>> (msg=msg@entry=0x7ffff793f693 "stack smashing detected") at
>>> fortify_fail.c:31
>>> #4  0x00007ffff78d2110 in __stack_chk_fail () at stack_chk_fail.c:28
>>> #5  0x00007ffff7b96553 in encode_mcu_huff (cinfo=0x7fffffffdd70,
>>> MCU_data=0x602720) at jchuff.c:641
>>> #6  0x00007ffff7b89717 in compress_output (cinfo=0x7fffffffdd70,
>>> input_buf=<optimized out>) at jccoefct.c:381
>>> #7  0x00007ffff7b89006 in jpeg_finish_compress (cinfo=0x7fffffffdd70) at
>>> jcapimin.c:183
>>> #8  0x0000000000401196 in main () at test-768369.c:205
>>>
>>>
>>>
>>>
>>

---

Message #148 received at 768369@bugs.debian.org (full text, mbox, reply):

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=768369#114
> 
> I created a minimal test case in around 200 lines.
> 
> It uses a file with the intercepted scanlines of the calls to jpeg_write_scanlines.
> 
> Also the Exif marker is read from such a file.
> (And without this Exif marker the stack smash does not happen...)

Use CVE-2014-9092.

- -- 
CVE assignment team, MITRE CVE Numbering Authority
M/S M300
202 Burlington Road, Bedford, MA 01730 USA
[ PGP key available through http://cve.mitre.org/cve/request_id.html ]
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.14 (SunOS)

iQEcBAEBAgAGBQJUdYGqAAoJEKllVAevmvmsA7QH/ijNNlUkWF2Vst56xw9AZNUN
dYdTRNXISkzOotHcglCpOomIzjbTWy4ablsLxryr0kUc4ZjIc5RlZuCTKAaVJ+EC
RgphhkmFHkKNqPSVMLtIOpP4ZX/0uPSKAMlzoXsRzRgmEBG6pnYnokJTa47sit26
iSpvAqXUNwJ/ZA14eUFMDdP6FbpOB4wmHS9h5nnUO7lzhmM/93XasD6WluBB0EBo
F9xZ/a0pCfEV+9RwKMiGsr2w+nPYDzUWlnrNbVnw8ou9msI/tolGadUbbwCM1NY9
FiemAFw4ZRExQIjDKaubApDlNuYzckmDNvBWJkwdVIJvBvQqNPVmUMP4MefDGhw=
=F4GF
-----END PGP SIGNATURE-----

---

Message #161 received at 768369@bugs.debian.org (full text, mbox, reply):

A small addition to the test case in Message #114:

In test-768369.c lines 193 and 194 are swapped therefore an
undefined value is given to malloc.

When cleaning up this leads to a crash as now the stack
smashing is fixed.

Kind regards,
Bernhard

---

Send a report that this bug log contains spam.

---

Debian bug tracking system administrator <owner@bugs.debian.org>. Last modified: Wed Jun 19 17:36:09 2019; Machine Name: buxtehude

Debian Bug tracking system

Debbugs is free software and licensed under the terms of the GNU Public License version 2. The current version can be obtained from https://bugs.debian.org/debbugs-source/.

Copyright © 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson, 2005-2017 Don Armstrong, and many other contributors.