You need to log in before you can comment on or make changes to this bug.
Created an attachment (id=851) [details] poc for tiff2pdf in libtiff 4.0.9
(In reply to comment #0) > An error caused by an NULL pointer when using tiff2pdf tool in the latest libtiff4.0.9. and the latest jpegsrc.v9c.tar.gz(http://www.ijg.org/). command tiff2pdf -j -o output.pdf poc.tif The asan report is : ================================================================= Starting program: /usr/local/bin/tiff2pdf -j -o output.pdf poc.tif [Thread debugging using libthread_db enabled] Using host libthread_db library "/lib64/libthread_db.so.1". Program received signal SIGSEGV, Segmentation fault. jpeg_fdct_16x16 (data=0x7fffffffdf90, sample_data=0x62cb90, start_col=0) at jfdctint.c:2213 2213 tmp0 = GETJSAMPLE(elemptr[0]) + GETJSAMPLE(elemptr[15]); Missing separate debuginfos, use: debuginfo-install glibc-2.17-106.el7_2.4.x86_64 xz-libs-5.1.2-12alpha.el7.x86_64 zlib-1.2.7-15.el7.x86_64 (gdb) bt #0 jpeg_fdct_16x16 (data=0x7fffffffdf90, sample_data=0x62cb90, start_col=0) at jfdctint.c:2213 #1 0x00007ffff770ad86 in forward_DCT (cinfo=<optimized out>, compptr=0x6292f8, sample_data=0x62cb90, coef_blocks=<optimized out>, start_row=<optimized out>, start_col=0, num_blocks=27) at jcdctmgr.c:91 #2 0x00007ffff7709ec2 in compress_first_pass (cinfo=0x6284f0, input_buf=0x628998) at jccoefct.c:288 #3 0x00007ffff7707fa6 in jpeg_write_raw_data (cinfo=cinfo@entry=0x6284f0, data=data@entry=0x628998, num_lines=num_lines@entry=16) at jcapistd.c:154 #4 0x00007ffff7b8f10c in TIFFjpeg_write_raw_data (sp=sp@entry=0x6284f0, data=data@entry=0x628998, num_lines=num_lines@entry=16) at tif_jpeg.c:350 #5 0x00007ffff7b8f3db in JPEGEncodeRaw (tif=0x6133b0, buf=0x7ffff7ee4380 "\220\263ӗ\272ډ\260ـ\247\320~\244\323|\242щ\251ϑ\261ע\274˭\307ּ\320\317\300\324ӿ\327\327\275\325չ\325پ\332ެ\311ۙ\266\310b\230\362E{\325\025s\327\r", <incomplete sequence \317>, cc=<optimized out>, s=<optimized out>) at tif_jpeg.c:2183 #6 0x00007ffff7ba8e56 in TIFFWriteEncodedStrip (tif=tif@entry=0x6133b0, strip=strip@entry=0, data=data@entry=0x7ffff7ee2010, cc=497664) at tif_write.c:285 #7 0x0000000000404b84 in t2p_readwrite_pdf_image (t2p=t2p@entry=0x611010, input=input@entry=0x611c20, output=output@entry=0x6133b0) at tiff2pdf.c:2739 #8 0x000000000040b7e1 in t2p_write_pdf (t2p=t2p@entry=0x611010, input=input@entry=0x611c20, output=output@entry=0x6133b0) at tiff2pdf.c:5567 #9 0x00000000004019fb in main (argc=<optimized out>, argv=<optimized out>) at tiff2pdf.c:808 SUMMARY: ================================================================= Breakpoint 2, jpeg_fdct_16x16 (data=0x7fffffffdf90, sample_data=0x62cb90, start_col=0) at jfdctint.c:2209 2209 elemptr = sample_data[ctr] + start_col; (gdb) p ctr $5 = 8 (gdb) p sample_data[8] $6 = (JSAMPROW) 0x0 (gdb) n 2213 tmp0 = GETJSAMPLE(elemptr[0]) + GETJSAMPLE(elemptr[15]); (gdb) n Program received signal SIGSEGV, Segmentation fault. jpeg_fdct_16x16 (data=0x7fffffffdf90, sample_data=0x62cb90, start_col=0) at jfdctint.c:2213 2213 tmp0 = GETJSAMPLE(elemptr[0]) + GETJSAMPLE(elemptr[15]); (gdb) bt #0 jpeg_fdct_16x16 (data=0x7fffffffdf90, sample_data=0x62cb90, start_col=0) at jfdctint.c:2213 #1 0x00007ffff770ad86 in forward_DCT (cinfo=<optimized out>, compptr=0x6292f8, sample_data=0x62cb90, coef_blocks=<optimized out>, start_row=<optimized out>, start_col=0, num_blocks=27) at jcdctmgr.c:91 #2 0x00007ffff7709ec2 in compress_first_pass (cinfo=0x6284f0, input_buf=0x628998) at jccoefct.c:288 #3 0x00007ffff7707fa6 in jpeg_write_raw_data (cinfo=cinfo@entry=0x6284f0, data=data@entry=0x628998, num_lines=num_lines@entry=16) at jcapistd.c:154 #4 0x00007ffff7b8f10c in TIFFjpeg_write_raw_data (sp=sp@entry=0x6284f0, data=data@entry=0x628998, num_lines=num_lines@entry=16) at tif_jpeg.c:350 #5 0x00007ffff7b8f3db in JPEGEncodeRaw (tif=0x6133b0, buf=0x7ffff7ee4380 "\220\263ӗ\272ډ\260ـ\247\320~\244\323|\242щ\251ϑ\261ע\274˭\307ּ\320\317\300\324ӿ\327\327\275\325չ\325پ\332ެ\311ۙ\266\310b\230\362E{\325\025s\327\r", <incomplete sequence \317>, cc=<optimized out>, s=<optimized out>) at tif_jpeg.c:2183 #6 0x00007ffff7ba8e56 in TIFFWriteEncodedStrip (tif=tif@entry=0x6133b0, strip=strip@entry=0, data=data@entry=0x7ffff7ee2010, cc=497664) at tif_write.c:285 #7 0x0000000000404b84 in t2p_readwrite_pdf_image (t2p=t2p@entry=0x611010, input=input@entry=0x611c20, output=output@entry=0x6133b0) at tiff2pdf.c:2739 #8 0x000000000040b7e1 in t2p_write_pdf (t2p=t2p@entry=0x611010, input=input@entry=0x611c20, output=output@entry=0x6133b0) at tiff2pdf.c:5567 #9 0x00000000004019fb in main (argc=<optimized out>, argv=<optimized out>) at tiff2pdf.c:808 (gdb)
The issue was assigned CVE-2018-10126
Please note I only forwarding the CVE assignment as noticed in the MITRE database at https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2018-10126 . Is this really an issue in tiff library, not in the the jpeg library?
(In reply to comment #4) > Please note I only forwarding the CVE assignment as noticed in the MITRE > database at https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2018-10126 . Is > this really an issue in tiff library, not in the the jpeg library?
(In reply to comment #4) > Please note I only forwarding the CVE assignment as noticed in the MITRE > database at https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2018-10126 . Is > this really an issue in tiff library, not in the the jpeg library? Obviously,crash happened in jpeg_fdct_16x16() at jfdctint.c:2213 2208 for (;;) { 2209 elemptr = sample_data[ctr] + start_col; //no judgment of sample_data[ctr] ==NULL 2210 2211 /* Even part */ 2212 2213 tmp0 = GETJSAMPLE(elemptr[0]) + GETJSAMPLE(elemptr[15]); The direct cause is no judgment of sample_data[ctr] !=NULL.and the Library function jpeg_fdct_16x16() is not rigorous. But because libtiff calls the library, and it enters an exception file.then causes a crash.As shown below. See the poc. Tif file. struct ENT dir[5] PhotometricInterpretation (262): eSHORT ... enum PHOTO value YCbCr (6) //[Normal should be RGB (2)] .... Then run cmd: "tiff2pdf -j -o output.pdf poc.tif " this results into different call branches. t2p_readwrite_pdf_image ->TIFFWriteEncodedStrip ->JPEGEncodeRaw //because of YCbCr(6), then enters this abnormal call branches ->TIFFjpeg_write_raw_data ->jpeg_write_raw_data ->compress_first_pass ->forward_DCT ->jpeg_fdct_16x16 if RGB(2),then will enter JPEGEncode --> ...->process_data_simple_main and then ->compress_first_pass ->forward_DCT ->jpeg_fdct_16x16 .It will no crash. so I think Libtiff also has the responsibility to limit exception calls.Do you think so?
(In reply to comment #4) > Please note I only forwarding the CVE assignment as noticed in the MITRE > database at https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2018-10126 . Is > this really an issue in tiff library, not in the the jpeg library? I looked into this a bit and came up with a few notes. May or may not be useful. :) 1. The segfault doesn't occur when using libjpeg-turbo instead of the IJG libjpeg. 2. Padding (at libtiff/tif_jpeg.c:2153) seems to get calculated incorrectly using the IJG software. (Added a few debug printfs) $ tiff2pdf -j -o output.pfd ../poc.tif Padding -432, width_in_blocks 54, clumps_per_line 432, hsamp 2. Padding -216, width_in_blocks 27, clumps_per_line 432, hsamp 1. Padding -216, width_in_blocks 27, clumps_per_line 432, hsamp 1. Padding -432, width_in_blocks 54, clumps_per_line 432, hsamp 2. Padding -216, width_in_blocks 27, clumps_per_line 432, hsamp 1. Padding -216, width_in_blocks 27, clumps_per_line 432, hsamp 1. Padding -432, width_in_blocks 54, clumps_per_line 432, hsamp 2. Padding -216, width_in_blocks 27, clumps_per_line 432, hsamp 1. Padding -216, width_in_blocks 27, clumps_per_line 432, hsamp 1. Padding -432, width_in_blocks 54, clumps_per_line 432, hsamp 2. Padding -216, width_in_blocks 27, clumps_per_line 432, hsamp 1. Padding -216, width_in_blocks 27, clumps_per_line 432, hsamp 1. Padding -432, width_in_blocks 54, clumps_per_line 432, hsamp 2. Padding -216, width_in_blocks 27, clumps_per_line 432, hsamp 1. Padding -216, width_in_blocks 27, clumps_per_line 432, hsamp 1. Padding -432, width_in_blocks 54, clumps_per_line 432, hsamp 2. Padding -216, width_in_blocks 27, clumps_per_line 432, hsamp 1. Padding -216, width_in_blocks 27, clumps_per_line 432, hsamp 1. Padding -432, width_in_blocks 54, clumps_per_line 432, hsamp 2. Padding -216, width_in_blocks 27, clumps_per_line 432, hsamp 1. Padding -216, width_in_blocks 27, clumps_per_line 432, hsamp 1. Padding -432, width_in_blocks 54, clumps_per_line 432, hsamp 2. Padding -216, width_in_blocks 27, clumps_per_line 432, hsamp 1. Padding -216, width_in_blocks 27, clumps_per_line 432, hsamp 1. Segmentation fault (core dumped) With libjpeg-turbo, looks a bit more sane. $ tiff2pdf -j -o output.df poc.tif Padding 0, width_in_blocks 54, clumps_per_line 216, hsamp 2. Padding 0, width_in_blocks 27, clumps_per_line 216, hsamp 1. Padding 0, width_in_blocks 27, clumps_per_line 216, hsamp 1. Padding 0, width_in_blocks 54, clumps_per_line 216, hsamp 2. Padding 0, width_in_blocks 27, clumps_per_line 216, hsamp 1. Padding 0, width_in_blocks 27, clumps_per_line 216, hsamp 1. clumps_per_line (sp->cinfo.c.comp_info[1].downsampled_width) doubled. IJG's libjpeg says this about jpeg_write_raw_data: If the image dimensions are not a multiple of the MCU size, the data must be padded to a multiple of a DCT block in each component, such that each downsampled row must contain a multiple of 8 valid samples, and there must be a multiple of 8 sample rows for each component. Data must be padded so that the passed num_lines value is atleast (cinfo->max_v_samp_factor * DCTSIZE). jpeg_write_raw_data() shall process one MCU row per call which is (cinfo->comp_info[0].v_samp_factor*DCTSIZE) sample rows of each component. Maybe the padding being off trips up libjpeg?
Bugzilla is no longer used for tracking libtiff issues. Remaining open tickets, such as this one, have been migrated to the libtiff GitLab instance at https://gitlab.com/libtiff/libtiff/issues . The migrated tickets have their summary prefixed with [BZ#XXXX] where XXXX is the initial Bugzilla issue number.
