You need to log in before you can comment on or make changes to this bug.
Created an attachment (id=503) [details] Sample TIFF file The attached file can be decoded by libtiff 3.9.4, but not by libtiff 3.9.5 and newer. The difference is caused by the fix for CVE-2011-0192. Test case: Using libtiff 4.0.3, $ tiffcp -c none testfax4.tif tmp.tif Actual result: Many warnings, starting with Fax4Decode: Bad code word at line 462 of strip 0 (x 2452). Fax4Decode: Warning, Premature EOL at line 462 of strip 0 (got 2452, expected 2453). Fax4Decode: Warning, Line length mismatch at line 463 of strip 0 (got 2460, expected 2453). Fax4Decode: Warning, Line length mismatch at line 465 of strip 0 (got 2454, expected 2453). ... The image is garbled starting at the first line reported in the warnings. Expected result: Maybe a warning message, but I would hope that the image could still be decoded as it is by v3.9.4. Most TIFF viewers successfully decode it.
Created an attachment (id=528) [details] Error pattern analysis on previously submitted image After some tests, I got to the conclusion that the error is caused by the condition (pa != thisrun) that was added to fix bug #2297 (http://bugzilla.maptools.org/show_bug.cgi?id=2297) in the DECODE2D macro (tif_fax3.h) : case S_VL: \ CHECK_b1; \ if (b1 <= (int) (a0 + TabEnt->Param)) { \ if (b1 < (int) (a0 + TabEnt->Param) || pa != thisrun) { \ unexpected("VL", a0); \ goto eol2d; \ } \ } \ SETVALUE(b1 - a0 - TabEnt->Param); \ b1 -= *--pb; \ break; When this condition is removed, the decoding is correct again. In the spreadsheet attachment I've added, I describe on tab 1 the image line configuration that triggers the error, based on the previously submitted image. It happens at the end of line #462. The final moves of the decoder on this line are an horizontal move, followed by a VL(1) on the last real column (2452) and a V(0) again on the last real column. This configuration leads into the exception evaluation, which is finally triggered because of the (pa != thisrun) condition. Interestingly, I asked a modified tiffcp ommitting the condition to produce a libtiff-encoded version of the image, and the libtiff encoder chooses another way to encode, with a final horizontal mode reaching directly the end of the line (see tab 2 of the attachment). I analyzed the same issue with another image, and the pattern was the same. After some encoding previously on the coding line (in this case a VR(2)), we reach a VL(1) on the last real column, followed by a V(0) still on the last real column. On both images, the graphic configuration is the same : - the reference line ends with white pixels followed by two black pixels and a final white pixel on the last column. - the coding line ends with black pixels followed by white pixels until the end of the line (I imagine there must be a condition on the number of final white pixels which induces the original encoder to choose its pattern). Now, I don't quite understand the meaning and usage of pa and thisrun in order to provide a patch, so any help would be appreciated. Furthermore, is there any testcase to check if a patch reintroduces the CVE-2011-0192 buffer overflow ? (the bug #2247 was a follow-up to security alert CVE-2011-0192)
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.
